MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 066

Internet Message Format | 1997-05-06 | 168KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-066
Date: Mon, 7 Nov 1994 16:29:31 +0100 (MET)

C.S.M.P. Digest             Mon, 07 Nov 94       Volume 3 : Issue 66

Today's Topics:

        #defines by the compiler (CodeWarrior)
        Announcement: New Mac C++ Programming Book Available
        Apple Guide:  Styled text FUBAR
        Basic GWorlds and QuickDraw Newbie
        CW & Code Resources -- poor?
        Desktop Pictures
        Drag-and-drop to cdev window?
        Fastest way to fill memory with a given value?
        Gestalt Selectors List 2.6
        Global storage in code resources
        How to execute MPW tools without MPW
        MacTCP Completion Routines & Async Nofification
        Memory Management within the Real World
        NewGWorld returns null pointer
        Pathnames? I don't think so...
        Q: Creating Variable sized structures?
        QuickTime + MIDI?
        Software volume locking: HELP!
        Some string routines for the PowerPC
        Tech Notes on the World Wide Web, and History Is Made



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (joe zobkiw)
Subject: #defines by the compiler (CodeWarrior)
Date: Mon, 17 Oct 1994 13:45:40 GMT
Organization: Datawatch Corporation

I have been writing some Aladdin InstallerMaker extensions recently and
have a nice little system that (using two projects and a "switch" in my
main source file) allows me to compile the extension as an application for
easy testing. Then, when I'm done, I can switch projects, switch the
#define switch in my main source file, and compile it as the proper
resource type.

My question is, since CodeWarrior doesn't have a nice little "Prefix" type
per-project option like THINK C had, is there another way? It would be
great if the compiler knew what TYPE it was compiling the code as and I
could get at this information in my code. Something like:

#ifdef APPL               // APPL is the TYPE of the project
  InitializeMacintoshManagers();
#endif

#ifdef IBeg               // IBeg is the RESOURCE TYPE of the project
   SysBeep(0);
#endif

Is there another way to accomplish this? Any thoughts?

_______________________________________________________ ,,,
Joe Zobkiw                         [e-mail] - -
Senior Software Engineer          Datawatch Corporation  L
___________ Zeros and Ones will take us there __________ _

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 17 Oct 1994 12:22:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (joe zobkiw) writes:

>>My question is, since CodeWarrior doesn't have a nice little "Prefix"
type per-project option like THINK C had, is there another way? It would
be great if the compiler knew what TYPE it was compiling the code as and I
could get at this information in my code.


The "Prefix File" option in the Languages Preferences lets you specify
a file that gets automatically prepended to every file. Be default, it is
set to the precompiled header for the Toolbox routines. However, you can
specify your own file.

For example, you could specify a Prefix File of  MyPrefix.h, where the
contents of MyPrefix.h was:

#include <MacHeaders68K>   // Included precompiled header
            // Define Symbols

#ifdef APPL               // APPL is the TYPE of the project
  InitializeMacintoshManagers();
#endif

#ifdef IBeg               // IBeg is the RESOURCE TYPE of the project
   SysBeep(0);
#endif

Your Prefix File can contain any valid C statements.

Ron Liechty
[e-mail]
Metrowerks Inc.



---------------------------

>From [e-mail] (DanParks)
Subject: Announcement: New Mac C++ Programming Book Available
Date: 15 Oct 1994 16:56:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

//******************************************************
   Apologies if this isn't the proper newsgroup for this message.
   I posted it to comp.sys.mac.announce, but it was returned as
         "not acceptable topic for this newsgroup" !!
//******************************************************

To All:

There's a new Mac programming book now available - "Symantec C++:
Object-Oriented Programming Fundamentals for the Macintosh" by Prima
Publishing. It should be at your bookstore by the time you read this.

"Symantec C++:  Object-Oriented Programming Fundamentals for the
Macintosh"
Dan Parks Sydow
Prima Publishing
ISBN:  1-55958-633-8

The book assumes the reader has a knowledge of a higher-level language -
preferably the C language. It also assumes the reader has done at least a
little programming on the Mac. No advanced-level programming skills are
needed, and no previous knowledge of C++ is required.

Like my previous Prima book, "Think THINK C", this book comes bundled with
a disk that contains ALL of the source code examples presented in the
book. It also has a tutorial software program that covers the major topics
from the book, from a little different perspective. That program is called
Simulator C++. The purpose of the software is to "bring to life" the
concepts in the book through the use of text, graphics, QuickTime movies,
and on-screen questions and answers.

All examples in the book work with Symantec C++ version 6 or version 7.
All examples run on either a 680x0 Mac or a Power Mac. There are a couple
of dozen example programs - most of them short and covering just a single
key topic. But there are also a couple of larger programs that incorporate
many C++/object-oriented programming concepts. Earlier examples stress
basic techniques, later examples stress programming C++ using Macintosh
techniques - writing programs that make use of menus, dialogs, windows,
resources, and graphics.

As always, please feel free to send email to me ( addresses shown below)
with any comments/suggestions/kind words/complaints/questions.

*Note to CodeWarrior Owners*
If you want to learn C++ programming for the Mac, this book MAY be for
you. You'd have to be willing to skip one chapter of the book, and make
minimal changes to the source code. You CodeWarrior owners shouldn't have
too much trouble adapting the examples to your Metrowerks compiler. You'll
need to create a new project, then add the included source code file to
it. Most source code files need only one or two changes to compile with
CodeWarrior. I'll be posting an errata sheet in this newsgroup next week
for CodeWarrior users. It will detail the changes that need to be made.

Internet:  [e-mail]
CompuServe:   73747,1401
America Online:  DanParks


Regards,

Dan



+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Mon, 17 Oct 1994 13:38:50 GMT
Organization: Datawatch Corporation

In article <37pfl4$[e-mail]>, [e-mail] (DanParks)
wrote:

> //******************************************************
>    Apologies if this isn't the proper newsgroup for this message.
>    I posted it to comp.sys.mac.announce, but it was returned as
>          "not acceptable topic for this newsgroup" !!
> //******************************************************
>

How could the Macintosh programmers newsgroup not be the right place for
an announcement about a new book about Macintosh programming? :)

This damn info-super-highway has everyone afraid of getting flamed for the
littlest thing, much like most kids in the inner-city are afraid to go to
school because they'll get shot. So what do they do? Skip school and not
post.

Dan, it sounds like a good book. Thanks for the info.

_______________________________________________________ ,,,
Joe Zobkiw                         [e-mail] - -
Senior Software Engineer          Datawatch Corporation  L
___________ Zeros and Ones will take us there __________ _

---------------------------

>From [e-mail] (Charles Wiltgen)
Subject: Apple Guide:  Styled text FUBAR
Date: Sat, 22 Oct 1994 18:09:26 -0500
Organization: Muso Communications

It's a major pain to use styled text in Apple Guide.  Basically, I can't
make any hypertext links stand out because Apple didn't think of including
an "embolden" tag in the dang compiler.

What is everyone using to create Apple Guide files with?  SimpleText is
out of the question.  I'd like to use WriteNow, but the GuideMaker crashes
when it tries to read it.

Anyone have a solution?

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 23 Oct 1994 11:01:58 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] (Charles Wiltgen) wrote:

>It's a major pain to use styled text in Apple Guide.  Basically, I can't
>make any hypertext links stand out because Apple didn't think of including
>an "embolden" tag in the dang compiler.

Yep, I've found this very annoying too.  I basically gave up on hot text,
at least for the moment.

>What is everyone using to create Apple Guide files with?

I use TexEdit.  It's a pretty cool shareware styled text editor.  [And
yes, I have sent off my shareware payment.]  Unfortunately there's no XTND
filter for it, so the styles don't move across to AG.

>I'd like to use WriteNow, but the GuideMaker crashes
>when it tries to read it.

I had *exactly* the same problem.  I think (god forbid) that MS Word might
be a good choice.  As long as you restrict yourself to the core features
it's fairly nice and the XTND filters are likely to be more stable.
However my hard disk is Microsloth-free, which eliminates this option for
me.

Share and Enjoy.
--
Quinn "The Eskimo!"      "I wasn't the one who fired the heat seeking
                          population annihilator out the window!"

+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Sun, 23 Oct 1994 12:43:14 -0500
Organization: Muso Communications

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

> >It's a major pain to use styled text in Apple Guide.  Basically, I can't
> >make any hypertext links stand out because Apple didn't think of including
> >an "embolden" tag in the dang compiler.
>
> Yep, I've found this very annoying too.  I basically gave up on hot text,
> at least for the moment.

That's potentially one of the Best Thingsª about Apple Guide, and we can't
use it because there's no way to find out what what's hot-clickable.  I'm
going to use Word on one of my smaller files (but I'm afraid!) or go to
some sort of Çclick hereÈ notation for now.

> >I'd like to use WriteNow, but the GuideMaker crashes
> >when it tries to read it.
>
> I had *exactly* the same problem.  I think (god forbid) that MS Word might
> be a good choice.  As long as you restrict yourself to the core features
> it's fairly nice and the XTND filters are likely to be more stable.
> However my hard disk is Microsloth-free, which eliminates this option for
> me.

Thanks for the confirmation.  I got WriteNow for $12.95 when I ordered
something from MacWarehouse (don't tell anyone about this special offer!)
and thought it would be perfect for this.  Alas, it was not to be.

C'mon, Apple!  Add those <B>style</B> tags!!!

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Sun, 23 Oct 1994 13:41:56 -0500
Organization: Muso Communications

In article <[e-mail]>,
[e-mail] (Charles Wiltgen) wrote:

> > I think (god forbid) that MS Word might
> > be a good choice.  As long as you restrict yourself to the core features
> > it's fairly nice and the XTND filters are likely to be more stable.
> > However my hard disk is Microsloth-free, which eliminates this option for
> > me.

Nope, Word doesn't work either (although Guide reads Word files fine).

Can someone from Apple help?  I've already started doing my hot words like
«this»...

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

---------------------------

>From [e-mail] (Jared P. O'neal)
Subject: Basic GWorlds and QuickDraw Newbie
Date: 18 Oct 1994 21:28:47 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


I've created a GWorld, at least I think I have.  Then, I used the
GetGWorldPixMap() call to get the handle of the PixMap.  All I wanted to do was
use CopyBits to take a picture I had put into the GWorld w/ DrawPicture onto a
window I had created, but when I tried it, it didn't copy anything into the
window.  When I tried to debug it (just how do you debug a GWorld), I noticed
that the baseaddr was 0, which doesn't seem right.  Is there anything I did
wrong here?  (I left out the error handling stuff)

GetGWorld(&origPort, &origDev);
    myErr = NewGWorld(&myGWorldPtr, 0, &myRect, nil, nil, 0);
    SetGWorld(myGWorldPtr, nil);
    myPixMapHnd = GetGWorldPixMap(myGWorldPtr);
    good = LockPixels(myPixMapHnd);
    wndoRect = myGWorldPtr->portRect;
    EraseRect(&wndoRect);

if (PictID != 0)
    {
        myPic = GetPicture(PictID);
        DrawPicture(myPic, &myRect);
    }

    SetGWorld(origPort, origDev);

    SetPort(wp);

CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect), 0, nil);

where wp is the WindowPtr of the destination window.

--Jared
--
Philosophy:  Master the colonel's secret blend of herbs & spices and all the
secrets of the universe will be yours!?!

Jared O'Neal aka [e-mail] or [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 19 Oct 1994 07:43:58 GMT
Organization: First Ascent

In article <381emf$[e-mail]>
[e-mail] (Jared P. O'neal) writes:

> Is there anything I did wrong here?
>CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect), 0, nil);

Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to
&((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And
(BitMap*)wp is wrong too. You want &((GrafPtr)wp)->portBits.

+++++++++++++++++++++++++++

>From [e-mail] (GBolsinga)
Date: 19 Oct 1994 15:24:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <382inu$[e-mail]>, [e-mail]
(Alex Curylo) writes:

>Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to
>&((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And

This is wrong! To quote NIM: Imaging With QuickDraw:
"To ensure compatibility on systems running basic QuickDraw instead of
Color Quickdraw, use GetGWorldPixMap whenever you need to gain
access to the bitmap created for a graphics world--that is, do NOT
dereference the GWorldPtr record for that graphics world."

The funny thing is, all the code samples for CopyBIts in the book that I
saw do the WRONG thing.  So many manuals, so little time... :)

The problem is with the second (destination) Bitmap: change it to:

&((GrafPtr)wp)->portBits

and thing should be fine.

Greg Bolsinga
MPI Multimedia

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 24 Oct 1994 09:15:00 GMT
Organization: First Ascent

In article <[e-mail]>
[e-mail] (Robert Coie) writes:

> A word of caution about GetGWorldPixMap -- it was severely broken in
> pre-7.0 systems.  I think it grabbed a half word instead of a full 32-bit
> word.  If you are certain to be running on a post-7.0 system,
> GetGWorldPixMap should be OK.  If you are certain that Color QuickDraw is
> present and are concerned about System 6 compatibility, do the direct
> dereference.

Yes indeed. Version 1.2, to be exact. Like this:

    // GetGWorldPixMap doesn't work in 32CQD 1.2
    gLameCQD = (qdVersion >= gestalt32BitQD) && (qdVersion <
gestalt32BitQD13);

// workaround for GetGWorldPixMap bug in CQD 1.2
PixMapHandle OurGetGWorldPixMap(GWorldPtr world)
{
 if (gLameCQD)
     return ((CGrafPtr)world)->portPixMap;
 else
     return GetGWorldPixMap(world);
}

But in the particular case of CopyBits,
&((GrafPtr)myGWorldPtr)->portBits really does always work. Up to 7.5,
anyway.

---------------------------

>From [e-mail] (Andrew Francke)
Subject: CW & Code Resources -- poor?
Date: Wed, 12 Oct 1994 03:00:02 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

After perusing CodeWarrior C for a little Component Manager
development, I've formed the following reactions. Please respond with
the approriate answers.

Is it just me, or:

* is there no way to create a single-segment code resource that uses
  the MW ANSI libs?

* does the faux-segment loader just plain not work when the code
  resource's resource fork isn't open? when there are multiple
  multi-segment resources in the same file?

* is there no way to have the following declaration in an MW
  code resource:

    char *foo = "bar"

If the answer to the first question is "yes," when will MW ship an
intelligent linker? Yes, yes -- it's way better than the
THINK/Symantec linker in its identification of dead code. That doesn't
matter if it's convinced you need multiple segments based on the
*un*stripped code/data size.

If the answer to any part of the second question is "yes," when will
MW either: document the secret inner-workings of the multi-segment
glue? Heck, if the answer is *no,* when will MW document it?

The third question is based on the fuzzy observation (i.e., I didn't
ATFCO -- adjust the compiler options) that a struct with a char *
member could not be initialized with a static string.

Finally -- on an entirely unrelated note -- when will somebody prepare
a runtime library for MPW C-generated .o files that need such fine
symbols as _iob and LDIVU -- that can then be used in MW projects.

+++++++++++++++++++++++++++

>From [e-mail] (IsoChrome)
Date: 13 Oct 1994 14:10:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Andrew
Francke) writes:

> * does the faux-segment loader just plain not work when the code
>  resource's resource fork isn't open? when there are multiple
>  multi-segment resources in the same file?

I've had the same problem with CW (we're writing 'cmm ' components). The
component manager seems to cache the component code, so your resource fork
isn't open when you are called. It looks like CW keeps some sort of jump
table information in a separate resource ('cmmx' for 'cmm 's). The kiss of
death is that the resource is loaded before a single line of your code is
executed (to get the address of main maybe?), so there is no way you can
open the resource fork yourself. I've had to punt and compile the 68K
piece in Symantec and the PPC piece in CodeWarrior.

John Sarapata

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: Sun, 16 Oct 1994 07:53:44 GMT
Organization: The Information Worskhop

In article <[e-mail]>, [e-mail] (Andrew
Francke) wrote:

Try posting your question in "comp.sys.mac.programmer.codewarrior" which
you may not have known existed.  It's new, and you may find an answer to
your question already posted, as I remember reading something along these
lines recently.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Richard Buckle)
Date: Tue, 18 Oct 1994 07:51:57 GMT
Organization: none

In article <[e-mail]>,
[e-mail] (Andrew Francke) wrote:

>* is there no way to create a single-segment code resource that uses
>  the MW ANSI libs?

Not if you want to use any vaguely useful ANSI function, such as pow() or
tolower(). The problem is the dead-code stripping can't see through
libraries.
I've repeatedly suggested that MW sort this out and in the interim either
distribute cut-down ANSI libraries (string.lib, math.lib etc) without
32-bit links hard-wired in or at the very least distribute a 68020 build. I
have got *nowhere*.

>* does the faux-segment loader just plain not work when the code
>  resource's resource fork isn't open? when there are multiple
>  multi-segment resources in the same file?

Basically yes. It can also crash horribly if your multi-segment resource is
unlocked between calls to it and moves, as the 32-bit jumps do not get
remade. UnloadA4Seg() does not help. I have asked MW to provide a way to
tell the multi-segment resource to remake its jumps, such as calling
UnloadA4Seg(NULL), but this too has fallen on deaf ears.
Dammit, I feel strongly I should be entitled to unlock my code resources
between calls to them.
As I have no control over the third party app calling my code resource, I
have been reduced to building a stub single-seg resource that calls the
multi-seg resource, runs it and disposes of it to suit MW's brain-damaged
segmentation scheme. Mail me if you want details.

The whole segmentation thing on CodeWarrior *sucks*, on apps as well as
code resources. See a thread by Steve Dorner a while ago for a description
of the pure evil that is the application segment loader under CW.

A dreadful shame, as this apart from this huge blind spot MW have a *very*
fine product. Maybe some more net.pressure will do the trick.


- -----------------------------------------------------
Richard Buckle
[e-mail]
Using this darned fine NewsHopper thingy.


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 18 Oct 1994 17:26:12 GMT
Organization: Apple Computer

Andrew Francke, [e-mail] writes:
> * does the faux-segment loader just plain not work when the code
>   resource's resource fork isn't open? when there are multiple
>   multi-segment resources in the same file?

I believe it will work as long as you preload and detach the code segments.
The loader obviously can't magically know how to open the resource file to
get the code.

> * is there no way to have the following declaration in an MW
>   code resource:
>     char *foo = "bar"

Should work fine as long as A4 is set up properly at the time that the global
data is referenced.

I've directed follow-ups to c.s.m.p.codewarrior.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Erik J. Rogers)
Date: Thu, 20 Oct 1994 01:59:30 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]> wrote:
: > * is there no way to have the following declaration in an MW
: >   code resource:
: >     char *foo = "bar"

: Should work fine as long as A4 is set up properly at the time that the global
: data is referenced.

Try using:
    char foo[] = "bar";

See "ReadMe Second" in WDEF sample of resource samples of CW CD for details.

Erik J. Rogers

---------------------------

>From [e-mail] (Howard Jacobowitz)
Subject: Desktop Pictures
Date: 16 Oct 1994 13:34:52 -0400
Organization: Rutgers University

I know of at least three INIT/cdev's that replaces the standard
desktop pattern with a PICT.  HOW?!?!?!?!?
I think it involves patching FillCRect/FillCRgn, althoug I've no idea why.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 17 Oct 1994 11:09:43 +0100
Organization: Royal Institute of Something or other

In article <37ro7s$[e-mail]>,
[e-mail] (Howard Jacobowitz) wrote:

>I know of at least three INIT/cdev's that replaces the standard
>desktop pattern with a PICT.  HOW?!?!?!?!?
>I think it involves patching FillCRect/FillCRgn, althoug I've no idea why.

This happens to do that, and also replace SysBeep() with a
predetermined sound, and also play a sound at startup.

This particular feature set was used for freshman education
earlier this year :-)

You can make it go faster by creating a GWorld and draw the
picture into it, and use CopyBits, and also re-create the
GWorld everytime the color environment changes. Cache the PICT
to disk when you do, instead of keeping it, too, in memory.

Compile with Think C 7

//    Note:
//    Build this as an INIT; the resource flags HAVE to be System Heap, Locked and Preload
//
//    Install two "snd " resources; 4000 for the system beep and 4001 for the
//    startup sound
//    Both these resources HAVE to have the System Heap and Locked bits set;
//    it helps if they also have the Preload bit set (in Resource info in ResEdit)
//
//    Install a PICT resource; ID 4000. This PICT HAS to have the System Heap and Locked
//    bits set; it helps with the Preload bit as well (in Resource info in ResEdit)
//    This PICT will be drawn in the background (on the desktop) - note that the PICT
//    has to be rectangular (square) and the same size as your screen(s) to look best.
//
//    Screen sizes are:
//    PowerBook        640x400
//    13"/14"            640x480
//    15" portrait    640x870
//    16"/17"            832x624
//    19"                1024x768
//    19"/21"            1182x870
//
//    ©1994 Jon Wätte    [e-mail]


#include <SetupA4.h>
#include <Traps.h>
#include <Sound.h>


Handle theBeep = NULL ;

static pascal void
DoBeep ( short time )
{
    SetUpA4();
    if ( theBeep ) {
        SndPlay ( NULL , theBeep , false ) ;
    }
    RestoreA4();
}


static void
PlayStart ( )
{
    Handle h = GetResource ( 'snd ' , 4001 ) ;
    if ( h ) {
        SndPlay ( NULL , h , false ) ;
        ReleaseResource ( h ) ;
    }
}


pascal void ( * oldFillCRgn ) ( RgnHandle rgn , PixPatHandle pat ) ;

PicHandle thePict = NULL ;


static pascal void
DrawDesk ( RgnHandle rgn , PixPatHandle pat )
{
    SetUpA4 ( ) ;
    if ( ! EmptyRgn ( rgn ) )
    {
        // DeskCPat -- only works on color QD machines
        if ( ( pat == * ( PixPatHandle * ) 0xcd8 ) &&
            ( thePict != NULL ) )
        {
            RgnHandle clip = NewRgn ( ) ;
            RgnHandle temp = NewRgn ( ) ;
            Rect r = ( * * GetGrayRgn ( ) ) . rgnBBox ;
            GetClip ( clip ) ;
            SectRgn ( clip , rgn , temp ) ;
            SetClip ( temp ) ;
            DisposeRgn ( temp ) ;
            if ( r . top > 0 )
                r . top = 0 ;
            DrawPicture ( thePict , & r ) ;
            SetClip ( clip ) ;
            DisposeRgn ( clip ) ;
        }
        else
        {
            ( * oldFillCRgn ) ( rgn , pat ) ;
        }
    }
    RestoreA4 ( ) ;
}


main()
{
    // Some glue to safely install ourselves
    asm {
        move.l a0,-(a7)
        dc.w 0xa128 // _RecoverHandle
        move.l a0,-(a7)
        dc.w 0xa992 // _DetachResource
        move.l (a7)+,a0
    }
    RememberA0();
    SetUpA4();
    PlayStart ( ) ;
    if ( ! Button ( ) )
    {
        if ( ( thePict = ( PicHandle ) GetResource ( 'PICT' , 4000 ) ) != NULL )
        {
            DetachResource ( ( Handle ) thePict ) ;
            oldFillCRgn = ( pascal void ( * ) ( RgnHandle , PixPatHandle ) ) GetToolTrapAddress ( 0xaa12 ) ;
            SetToolTrapAddress ( ( ProcPtr ) DrawDesk , 0xaa12 ) ;
        }

        theBeep = GetResource ( 'snd ' , 4000 ) ;
        if ( theBeep ) {
            DetachResource ( theBeep ) ;
            SetToolTrapAddress ( ( ProcPtr ) DoBeep , 0xA9C8 ) ; // SysBeep
        }
    }
    RestoreA4();
}



--
  Jon Wätte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"Smart Friends ask no SCSI questions!"
    — Apple employee at the Bash


---------------------------

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Drag-and-drop to cdev window?
Date: 10 Oct 94 16:47:53 +1300
Organization: University of Waikato, Hamilton, New Zealand

I'm writing this control panel which supports the Drag Manager. I've hit an
odd problem: dragging Finder clipping files to my window doesn't seem to work.

I stepped through my drag-tracking handler with MacsBug, and watched it check
for a PICT item type, by calling GetFlavorDataSize. If there is no PICT type,
I get badDragFlavorErr = -1852, which makes sense. If there _is_ a PICT type,
I get cantGetFlavorErr = -1854 instead.

If I drag a PICT item from another application to my control panel window,
it works OK, so I figure a bug in my code is unlikely. :-)

Anybody else encountered this? Maybe the problem is that control panels
run in the Finder's context, and its peculiar uses of the Drag Manager don't
allow for this.

Any ideas welcomed.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 11 Oct 1994 01:03:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) writes:

>I'm writing this control panel which supports the Drag Manager. I've hit
>an odd problem: dragging Finder clipping files to my window doesn't seem
>to work.

We had the same report at work and the answer is, it won't work.  I can't
remember the reason why, but Nitin tracked it down.

- Jim Luther

---------------------------

>From [e-mail] (Randy Jones)
Subject: Fastest way to fill memory with a given value?
Date: 14 Oct 1994 17:58:54 GMT
Organization: NWNEXUS, Inc. - We Make Internet Easy

I want to fill a given block of memory with copies of a long.
I'm guessing there has to be a faster way than a loop which
sets each word in turn.  BlockMove, for example, runs faster
than a copy loop.  But there's no Mac toolbox equivalent of
memset that I've found.

Are compilers smart enough to turn my loop of word writes into
something faster, maybe involving the MMU?  If not, then what
am I missing?  Think and/or MetroWerks C, BTW.

--Randy Jones



+++++++++++++++++++++++++++

>From [e-mail] (Richard Elmore)
Date: Sat, 15 Oct 1994 01:54:09 -0800
Organization: Northwest Nexus Inc.

In article <37mgsu$[e-mail]>, [e-mail] (Randy
Jones) wrote:

> I want to fill a given block of memory with copies of a long.
> I'm guessing there has to be a faster way than a loop which
> sets each word in turn.  BlockMove, for example, runs faster
> than a copy loop.  But there's no Mac toolbox equivalent of
> memset that I've found.

The most common way to speed up mem copy/fill operations is to unroll your
loop.  That is, instead of copying one long word during each iteration of
your loop copy several.  This is in fact the approach taken by
_BlockMove.  Another thing that will make a difference is to make sure all
of your moves are longword aligned (ever notice how Hypercard snaps its
windows an invisible grid on the screen, thats why).

--
Richard Elmore
[e-mail]

+++++++++++++++++++++++++++

>From Arnold Kim <[e-mail]>
Date: 16 Oct 1994 20:26:04 GMT
Organization: Nemesis Productions

In article <37mgsu$[e-mail]> Randy Jones,
[e-mail] writes:
> I want to fill a given block of memory with copies of a long.
> I'm guessing there has to be a faster way than a loop which
> sets each word in turn.  BlockMove, for example, runs faster
> than a copy loop.  But there's no Mac toolbox equivalent of
> memset that I've found.

If you want an only-68k solution, then probably the fastest you'll get is
the "movem" command in 68000 assembly.

What it does is move the contents of multiple registers into a desired
memory location.... so....

initialize all registers as 0x11111111
set a7 as the pointer to where you're writing

movem.l  a0-a6/d0-d7,(a7)+

that'll blast out 15 longs where (a7) is...

(that's probably not the exact syntax, and you'd want to preserve a7,
amongst other things... but that's the gist of it - check a 680x0
assembly book)

arnold

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Mon, 17 Oct 1994 01:26:18 -0500
Organization: University of Illinois at Urbana-Champaign

In article <37s28s$[e-mail]>, Arnold Kim
<[e-mail]> wrote:

> In article <37mgsu$[e-mail]> Randy Jones,
> [e-mail] writes:
> > I want to fill a given block of memory with copies of a long.
>
> If you want an only-68k solution, then probably the fastest you'll get is
> the "movem" command in 68000 assembly.

Yes, both MOVEM, and MOVE16 on 68040's, are very good block move
instructions. There are lots of ways to use them in creative ways.

> initialize all registers as 0x11111111
> set a7 as the pointer to where you're writing
>
> movem.l  a0-a6/d0-d7,(a7)+

Aside from the syntax being bad (you can only work with pre-decrement in
this mode, not post-increment), even using that would be *very* bad. You
don't want to use A7 unless you disable interrupts, since any interrupt
that comes through will allocate space on the stack where A7 currently
points. If you want to use this method, leave A7 alone completely, move
the address of the end of the block into one of the other address
registers, move the value you want into all of the other registers, and
then do the MOVEM. Here's some sample code I wrote to do a block clear, 52
bytes at a time (4 bytes per register in 13 registers):

; Written in THINK C assembler, so some of the syntax is wierd
; Start with the address of block to clear in A0 and the length in D0

        move.l  d1,-(sp)    ; 12
        moveq   #0,d1       ;  4
        adda.l  d0,a0       ;  8
        cmpa.w  #1,a0       ; 10
        bcs.s   @0          ;  8/10
        move.b  d1,-(a0)    ;  8
        subq.l  #1,d0       ;  8
    @0  cmpi.l  #160,d0     ; 14
        blt.s   @5          ; 10/8

        swap    d0                      ;  4
        move.w  d0,d1                   ;  4
        beq.s   @1                      ;  8/10
        divu.w  #52,d1                  ;144
        swap    d1                      ;  4
        move.w  d1,d0                   ;  4
    @1  swap    d0                      ;  4
        divu.w  #52,d0                  ;144
        move.w  d0,d1                   ;  4
        clr.w   d0                      ;  4
        swap    d0                      ;  4
        movem.l d0/d2-d7/a1-a6,-(sp)    ;112
        move.l  d1,d0                   ;  4
        moveq   #0,d1                   ;  4
        move.l  d1,d2                   ;  4
        move.l  d1,d3                   ;  4
        move.l  d1,d4                   ;  4
        move.l  d1,d5                   ;  4
        move.l  d1,d6                   ;  4
        move.l  d1,d7                   ;  4
        move.l  d1,a1                   ;  4
        move.l  d1,a2                   ;  4
        move.l  d1,a3                   ;  4
        move.l  d1,a4                   ;  4
        move.l  d1,a5                   ;  4
        move.l  d1,a6                   ;  4
        bra.s   @4                      ; 10
    @2  swap    d0                      ;  4
    @3  movem.l d1-d7/a1-a6,-(a0)       ;112
    @4  dbra    d0,@3                   ; 14/10
        swap    d0                      ;  4
        dbra    d0,@2                   ; 14/10
        movem.l (sp)+,d0/d2-d7/a1-a6    ;116 = 770

    @5  bclr    #2,d0       ; 14
        beq.s   @6          ;  8/10
        move.w  d1,-(a0)    ;  8
    @6  addq.b  #1,d0       ;  4
        lsr.l   #2,d0       ; 12
        bra.s   @9          ; 10
    @7  swap    d0          ;  4
    @8  move.l  d1,-(a0)    ; 12
    @9  dbra    d0,@8       ; 14/10
        swap    d0          ;  4
        dbra    d0,@7       ; 14/10
        addx.w  d0,d0       ;  4
        bpl.s   @10         ;  8/10
        move.b  d1,-(a0)    ;  8
    @10 move.l  (sp)+,d1    ; 12
        rts                 ; 16 = 252 +


pr
--
Pete Resnick    (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

>From [e-mail] (Rene G.A. Ros)
Subject: Gestalt Selectors List 2.6
Date: Wed, 12 Oct 1994 07:53:12 GMT
Organization: VU Biology, Amsterdam, The Netherlands

Dear Mac-programmers,


Today I released version 2.6 of the


                       Gestalt Selectors List (GSL)


This list celibrates its second anniversary today.

It lists all sorts of information about the Gestalt Manager, but mainly
about selectors and the meaning of the returned values.
The Gestalt Manager is part of the Apple Macintosh System Software to
enable programmers to determine the availability of certain software and
hardware.

You can obtain the latest version in several ways:
- by sending an email to the mail archive server:
      [e-mail]
  with as subject:
      archive get recent/gestalt-selectors.etx
  or to get the compressed version:
      archive get recent/gestalt-selectors.sit.hqx

- FTP to the info-mac archives at sumex-aim.stanford.edu and get the file
      /info-mac/dev/info/gestalt-selectors-26.hqx
  You can also use any of its mirror sites.

- World Wide Web
  The GSL is also available, together with other Macintosh FAQs, at:
      http://www.astro.nwu.edu/lentz/mac/faqs/source/gestalt.html

- CompuServe members can find it at the Macintosh Developers Forum
  (GO MACDEV) in the Tools/Debuggers section.

- Subscribers of the maillist have received their copy already.
  If you want to join this list you need to send an email to:
      [e-mail]
  with in the subject line 'subscribe'. You will then also receive
  several updates before the next version is released.

Please, be aware that it may take a couple of days before the new version
is available at all these locations. It is available immediatly by using
the mail archive server.

Beside a large number of new and changed selectors, these are the major
changes since the previous version:

***************************************************************************
Added selectors
  Apple System  : -
  Apple Add.    : fsm , srta, srtb, ws 1
  Third Parties : CsWT, FPUE, PPP
Added unknown
  Apple Softw.  : diag, jkbd, lang, mtem, ot
  Third Parties : *DC*, AlaC, Blad, Cafe, FW14, Mgc!, SNIT, SPAL, SPLO
Changed selectors
  Apple System  : a/ux, afps, cfrg, csvr, ctbv, cpnt, dplv, dply, easy,
                  fndr, fs  , gval, hdwr, help, hscd, icon, intd, kbd ,
                  mach, mbox, proc, qd  , qdrw, sdev, sdvr, snhw, sysv,
                  vm  , xlat
  Apple Add.    : cmta, cmtc, gfxa, grfx, ttsc
  Third Parties : jsm1, SAVR
Changed unknown
  Apple Softw.  : aslm, batt, bugx, bugy, dude, dudi, fnda, fnd*, fndc,
                  port
  Third Parties : FWCP, ReSp
Previously unknown
  Apple System  : scsi
  Apple Add.    : -
  Third Parties : Cafe
Includes updates 2.5.1 up to and including 2.5.10, sent to subscribers of
the mailing list.

The new Inside Macintosh Operating System Utilities is available (at least
electronically) and a few pieces of information in the GSL are corrected or
added. I see no reason to change the basics for the GSL, new selectors and
attribute bits will keep appearing as the system software develops...

The note about the gestaltKeyboardType selector not being installed on
the PowerMac 7100/66 was triggered by an Usenet posting by Marc Cooperman.
His observation was confirmed by me because Gestalt! reports of the
PM 7100/66 indeed do not list this selector, but I never noticed this when
I received these reports! Other (Power)Macs don't seem to have this
problem.

The GSL has been made available by Robert Lentz on a World Wide Web server.
It now has the latest version and a reference to it is included with the
'About This List/Availability' section.

Included information from the:
 - Bookmark CD #18,
 - Bookmark CD #19,
 - WWDC 1994 CD,
 - Developer CD Series August 1994 Tool Chest CD and
 - Developer CD Series September 1994 Reference Library CD.

Roland Mansson provided the information from the latest Gestalt &
SysEnvirons TechNote (rev. September 1994). The most important news
is that the machine ID's will be reused...

The following selectors are now installed with software included with
System 7.5 and are moved from the 'Apple Additional Software' to the 'Apple
System Software' section:
      ascr, ascv, aucd, cpkr,
      drag, hscd, icmp, iscd,
      kpcd, mtcp, qtim, qtrs,
      scra, sdev, sdvr, snhw,
      teat, thds, ufox, xlat
And these from the unknown 'Third Party Software' to the unknown 'Apple
Software' section:
      CDJR, HAM , MClk
***************************************************************************


Best regards,
Rene Ros
[e-mail]

--
  Rene G.A. Ros           [e-mail]          Amsterdam, The Netherlands
- ------------------------------------------------------------------------------
  English is deliberately designed to frustrate foreigners, you know...
  (Jeremy Roussak (UK) while trying to explain 'an/a' to me)

---------------------------

>From [e-mail] (Dan McDonald)
Subject: Global storage in code resources
Date: 14 Oct 1994 17:13:29 GMT
Organization: Information Technology Division, Naval Research Laboratory


With the advent of PowerPC, I'm again confused on something I thought I
knew.

I assumed that:

    * Global variables between procedures in a separate code resource
      were okay, as long as A4 was set up properly

If that assumption was wrong, fine.  If it's right, then

    * How the HELL do you set up A4 in PowerPC code resources?

I may end up designing my external code modules such that the module asks
the main program for storage, and the main program delivers, and
subsequently sends pointers to it whenever the code in the module is called.

Any comments, hints, death threats, etc. are vastly appreciated.
--
Daniel L. McDonald | Mail:  [e-mail] -------------------------+
Computer Scientist | WWW:   http://wintermute.itd.nrl.navy.mil/danmcd.html   |
Naval Research Lab | Phone: [phone]        #include <disclaimer.h>    |
Washington, DC     | "Rise from the ashes, A blaze of everyday glory" - Rush +

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Sat, 15 Oct 1994 19:09:29 GMT
Organization: ISIS International

In article <37me7q$[e-mail]>, [e-mail]
(Dan McDonald) wrote:

> With the advent of PowerPC, I'm again confused on something I thought I
> knew.
>
> I assumed that:
>
>         * Global variables between procedures in a separate code resource
>           were okay, as long as A4 was set up properly
>
> If that assumption was wrong, fine.  If it's right, then
>
>         * How the HELL do you set up A4 in PowerPC code resources?
>
68K code resources still need to have A4 set up, but you don't have to do
anything in native code resources. In PPC code, every code fragment
(including code resources) has its own global space accessible thru the
RTOC, which a register is always pointing to when that code fragment is
executing.

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: ftp://ftp.netcom.com/pub/isis/home.html

---------------------------

>From [e-mail] (Zack T. Smith)
Subject: How to execute MPW tools without MPW
Date: Wed, 12 Oct 1994 13:58:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Hi,

I'd like to find out how I can execute MPW commands without
having MPW. I know that there is a program available for
doing this (toolserver), but I don't want to use it.

I notice that the MPW tool that I have (gcc) contains only code
and version resources. I've tried to execute that as a
standalone app by changing creator to FNDR and type to APPL,
but the program immediately exits.

Does anyone know why this might be happening, assuming that gcc
is not buggy. I've tried to inquire with Apple via email, but
they won't respond. My guess is that, if gcc had been
executing properly, it simply didn't find any params to work on,
so it exited.

Would anyone know whether it's necessary to load MPW tools
into memory in order to execute them and pass parameters?

Thanks for any info,

Zack Smith


+++++++++++++++++++++++++++

>From [e-mail] (Stan Shebs)
Date: Wed, 12 Oct 1994 18:52:22 GMT
Organization: /cygint/s1/users/shebs/.organization


In article <[e-mail]> [e-mail] (Zack T. Smith) writes:

   I notice that the MPW tool that I have (gcc) contains only code
   and version resources. I've tried to execute that as a
   standalone app by changing creator to FNDR and type to APPL,
   but the program immediately exits.

Uh, MPW GCC requires considerable MPW infrastructure - for one thing,
it is a collection of tools, for another, it expects to be able to use
the MPW Assembler.  And where do you plan to get include files and
libraries?  Changing the file type to get it to run is about like
working the shift lever on an engineless car - it *might* start
rolling if you happen to shift into neutral while on a downhill slope...

MPW GCC needs a full MPW environment in order to be used.  Jonathan
Kimmitt has hacked up a standalone version, but it has a number of
limitations (the last time I looked, it couldn't build itself, for
instance).

   Does anyone know why this might be happening, assuming that gcc
   is not buggy. I've tried to inquire with Apple via email, but
   they won't respond. My guess is that, if gcc had been
   executing properly, it simply didn't find any params to work on,
   so it exited.

It's not that "Apple won't respond", it's that there's nobody there
*to* respond.  MPW GCC is not an Apple product, it was a project I
did while in Apple's ATG (and as you might guess from the address below,
I'm no longer there).  If you use it with MPW, it works just fine.

(For those more knowledgeable who might be wondering, yes Cygnus
would be willing to do an updated Mac GCC, *if* appropriate funding
were to be provided - I have no spare time these days :-( )

                            Stan Shebs
                            Cygnus Support
                            [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 12 Oct 1994 09:52:59 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Zack T. Smith) wrote:

> Hi,
>
> I'd like to find out how I can execute MPW commands without
> having MPW. I know that there is a program available for
> doing this (toolserver), but I don't want to use it.
>
> I notice that the MPW tool that I have (gcc) contains only code
> and version resources. I've tried to execute that as a
> standalone app by changing creator to FNDR and type to APPL,
> but the program immediately exits.

MPW (and ToolServer) provides a considerable amount of environment in
which MPW tools operate.  (Including in MPW's case a "foreign file system"
so that the tool access the current content of a window being edited, when
it thinks it is opening a file by that name.)

What you want to do is not impossible (witness Think/Symantec's SARez and
SADerez, which are apps which provide the needed environment), but more
trouble than it's worth.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Zack T. Smith)
Date: Fri, 14 Oct 1994 23:48:09 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]> [e-mail] (Stan Shebs) writes:
>
>In article <[e-mail]> [e-mail] (Zack T. Smith) writes:
>
>   I notice that the MPW tool that I have (gcc) contains only code
>   and version resources. I've tried to execute that as a
>   standalone app by changing creator to FNDR and type to APPL,
>   but the program immediately exits.
>
>Uh, MPW GCC requires considerable MPW infrastructure - for one thing,
>it is a collection of tools, for another, it expects to be able to use
>the MPW Assembler.  And where do you plan to get include files and
>libraries?  Changing the file type to get it to run is about like
>working the shift lever on an engineless car - it *might* start
>rolling if you happen to shift into neutral while on a downhill slope...

Libs and header files are available from ftp.apple.com.

MPW asm can be replaced with GNU asm (gas).

Much of the "infrastructure" would be provided through my C Shell,
assuming you mean environment variables, scripting, access to other
tools.

>MPW GCC needs a full MPW environment in order to be used.  Jonathan
>Kimmitt has hacked up a standalone version, but it has a number of
>limitations (the last time I looked, it couldn't build itself, for
>instance).

Has anyone got Kimmit's email address?

>   Does anyone know why this might be happening, assuming that gcc
>   is not buggy. I've tried to inquire with Apple via email, but
>   they won't respond. My guess is that, if gcc had been
>   executing properly, it simply didn't find any params to work on,
>   so it exited.
>
>It's not that "Apple won't respond", it's that there's nobody there
>*to* respond.  MPW GCC is not an Apple product, it was a project I
>did while in Apple's ATG (and as you might guess from the address below,
>I'm no longer there).  If you use it with MPW, it works just fine.
>
>(For those more knowledgeable who might be wondering, yes Cygnus
>would be willing to do an updated Mac GCC, *if* appropriate funding
>were to be provided - I have no spare time these days :-( )
>
>                            Stan Shebs
>                            Cygnus Support
>                            [e-mail]

Zack Smith

+++++++++++++++++++++++++++

>From [e-mail] (Judy Ann Kettenhofen)
Date: 23 Oct 1994 09:04:32 GMT
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)

Zack T. Smith ([e-mail]) wrote:
: In article <[e-mail]> [e-mail] (Stan Shebs) writes:
: >
: >In article <[e-mail]> [e-mail] (Zack T. Smith) writes:
: >
: >   I notice that the MPW tool that I have (gcc) contains only code
: >   and version resources. I've tried to execute that as a
: >   standalone app by changing creator to FNDR and type to APPL,
: >   but the program immediately exits.
: >
: >Uh, MPW GCC requires considerable MPW infrastructure - for one thing,
: >it is a collection of tools, for another, it expects to be able to use
: >the MPW Assembler.  And where do you plan to get include files and
: >libraries?  Changing the file type to get it to run is about like
: >working the shift lever on an engineless car - it *might* start
: >rolling if you happen to shift into neutral while on a downhill slope...

: Libs and header files are available from ftp.apple.com.

: MPW asm can be replaced with GNU asm (gas).

: Much of the "infrastructure" would be provided through my C Shell,
: assuming you mean environment variables, scripting, access to other
: tools.

You just aren't going to be able to run an MPW tool as an app, at
least very easily.  I suspect it is more trouble than it is worth.

An MPW tool has some curious code that is executed in the runtime.o
library.  This code basically hooks up the tools' input/output to
the Shell's.  You can think of it as almost like a dynamically-linked
library.  To give you some idea of which routines, do a dumpobj of
stubs.o, a library generally included when making tools; you'll notice
that most of these routines are simply empty routines.  They are there
to make the linker happy; they aren't used other than for that.

Stubs.o, plus other mechanisms, are used by tools running under the
Shell to provide the ability, as someone has pointed out, to deal
with the contents of open (and unsaved) windows.

 IF you could talk Apple out of telling you *exactly* how
this works, you might be able to build something around the tool to
provide those services; but the tool, in and of itself does not
contain those services.  (Altho', if I recall correctly, someone
within Apple once made one of the MPW tools so that it was able to
determine whether it was running as a tool or as an app and do the
appropriate thing.).

==Judy

--former MPW/ToolServer/Asm Hack.

---------------------------

>From Jon Lipsky <[e-mail]>
Subject: MacTCP Completion Routines & Async Nofification
Date: 18 Oct 1994 20:45:22 GMT
Organization: Case Western Reserve University

I am having trouble getting async connections working with
my TCP library I am working on.  I had no problems getting
syncronous connection to work.

I was wondering if there were bugs in the TCP header files
with the Completion Rountine, and Async Notification Routine
prototypes.  If anyone could help me out, I would appreciate
it.

Thanks in advance,

Jon...

+++++++++++++++++++++++++++

>From Aaron Wohl <[e-mail]>
Date: Wed, 19 Oct 1994 08:01:07 -0400
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 18-Oct-94 MacTCP
Completion Routines .. Jon [e-mail] (363)

> I was wondering if there were bugs in the TCP header files
> with the Completion Rountine, and Async Notification Routine
> prototypes.  If anyone could help me out, I would appreciate
> it.


No none that I know of.   However, the compleation routine is called
from interrupt level.  If you haven't done this sort of thing before it
is almost impossible to get it right.    The key items are:

- be carefull of the registers, like A5 isn't setup so you can't access
any globals
- some compilers generate functionc calls off of A5 so you may not be able
to call anything before A5 is setup.
- You can't call hardly any of the mac OS system calls.

For debugging such code take a look on host akutaktak.andrew.cmu.edu
[128.2.35.1] in /aw0g/softkiss*.*.   There is a debugging printf that
can be called from hardware interrupt level.  It writes directly to the
screen memory so you can even call it from a VBL, inside a trap patch
etc.

A sample async notification routine:

/*
 * handle incomming data or connection drop
 */
static pascal void myTCPNotifyProc(StreamPtr tcpStream,
    unsigned short eventCode,
    Ptr userDataPtr,
    unsigned short terminReason,
    struct ICMPReport *icmpMsg)
{
    register tcp_conv_pt acnv=(tcp_conv_pt)userDataPtr;

    acnv->last_event=eventCode;
    acnv->service_me=TRUE;

    switch (eventCode) {
        case TCPTerminate:
            acnv->terminating++;
            break;
        case TCPClosing:
            acnv->closing++;
            break;
        case TCPULPTimeout:
            break;
        case TCPDataArrival:
            acnv->data_arrived++;
            break;
        case TCPUrgent:
            break;
        case TCPICMPReceived:
            break;
        default:
            break;
        }
}

Async compleation routines should similarly be kept very simple.
Aaron Wohl / ham callsign N3LIW / 412-731-3691 / 412-268-5032

---------------------------

>From [e-mail] (Jeff Beeghly)
Subject: Memory Management within the Real World
Date: 17 Oct 1994 06:11:53 GMT
Organization: University of Washington

Well, the app which I am writing is up to the fully functioning stage, so
now I have to tackle those neat real world scenarios .... like gracefully
handling error conditions, running under low memory scenarios, etc...
and I have several questions on issues which have come up recently.

1) Under a low memory condition (~6,000 to 7,000 bytes free) calling the
StandardGetFile toolbox call crashes my app.  When I ran my app under the
debugger (THINK C ver 6.0) and called my function, my machine locked up
(my app didn't even break to the THINK C debugger).  I've tried to narrow
down the conditions (for example, in my app I was originally using a
custom file open dialog box), but right now I am just using
StandardGetFile(0L, -1, 0L, &reply), and when I call this function (e.g.
when I select the menu item that calls this function), I'm not calling
anything else, so I'm VERY CONFIDENT that it is the system call that is
crashing, not something that I have done (I've been working as a
professional software tester for several years now.. believe me, I know
how to isolate a bug    ;-)  ).

Is this a known fact?  Does StandardGetFile crash under low memory
conditions?  Do I have to do something like the following, just to ensure
that my app doesn't crash?

if(FreeMem() >7000L)
{
    StandardGetFile(0L, -1, 0L, &reply);
}
else
{
    //flash an alert and warn the user
}


2) In one of my dialogs, I am loading four separate pictures (only one
picture is displayed at a time) and displaying them to create an
'animation' effect within the dialog (OK.  yes.  it is my about dialog
box).  I'm doing something like the following:

while( !dlgDone )
{
    ModalDialog(AboutDlgProc, &dlgItem);
    dlgDone = (dlgItem == OK_ITEM || dlgItem == CANCEL_ITEM);
}

- -----------------------

pascal Boolean AboutDlgProc(DialogPtr theDialog, EventRecord *e, short *iPtr)
{
    static short step = 0;

    switch( e->what )
    {
        case keyDown:
        case autoKey:
            .
            .
            bla, bla, bla.... the usual
    }

    DoAnimation(theDialog, step);
    step++;
    if(step >= 4)
        step = 0;
}





void DoAnimation(DialogPtr theDialog, short step)
{
    PicHandle    pic;
    Rect        r;


    switch( step )
    {
        case 0:
            pic = GetPicture(128);
            break;

        case 1:
            pic = GetPicture(129);
            break;

        case 2:
            pic = GetPicture(130);
            break;

        case 3:
            pic = GetPicture(131);
            break;
    }


    if(pic != nil)
    {
        HLock( (Handle )pic );
        SetRect(&r, 20, 40, 20 + 124, 40 + 60);
        DrawPicture(pic, &r);
        HUnlock( (Handle )pic);
    }
}

Looks good so far, no?
Well, the problem is that under a low memory condition (say ~7,000 -
8,000 bytes free), the first picture is loaded and displays fine, but
when the second image is loaded, my app crashes (BTW:  each picture is
124 x 60 pixels x 256 colors and ResEdit said each were ~ 4500 bytes large).

I then went in and added a
    ReleaseResource( (Handle )pic);
call after the HUnlock call.  This time, each of the four pictures were
loaded (and my app didn't crash), but when the counter turned back to 0, the
first pic wasn't displayed.

I dismissed the dialog box and brought it back up again.  This time, none
of the pictures were displayed!  Well, this leads me to believe that when
I call ReleaseResource(), it not only frees up the memory of the handle
holding the picture, but it clears it from the current resource as well.
I then tried to use the DisposeHandle() call in place of the
ReleaseResource() call, and the same thing occurred (all four pictures
were displayed once and only once).


At this point, I added following:

if(pic != nil)
{
    .
    .
    .
}
else
{
    MoveTo(20, 20);
    DrawString("\pCan't open image");
}


I was thinking, OK, the problem is there is not enough memory to open the
image... that is why my app is crashing... I'll just check to see if the
PicHandle is nil.  If it is not nil, I will draw the picture.  If it is
nil, I will not draw the pic and continue on.

When I ran my program and brought up the dialog, the error message never
came up!


So what gives?  I can't load and display the image, yet the pic isn't nil
either!?!?!  (btw:  I did this for the case of when I try to release
memory (via ReleaseResource or DisposeHandle) and when I don't release
the Handle).



Do I need to do a lot of watch dogging and not let any operations be
performed if the app goes beneath 0k of memory is free?


3) In Macintosh C Programming Primmer Vol 2, it states that when a
program starts, it contains a block of master pointers.  It is within
this location that the location of the Handles are kept (64 of them).  If
the program requires more than 64, the MoreMasters() call needs to be
made (which will create 64 more locations for handles).  What happens if
I have filled up all 64 locations with handles, then create another
handle (for arguments' sake, let's say that there is enough memory to
create the size of the handle, and we create a new handle without
calling MoreMasters())?  Will I run the risk of loosing the handle when
memory is juggled around?

4) In my program, I manage multiple files at the same time (hence, my app
manages several windows at the same time).  In each file/window, there
are LOTS of different handles (my app displays dozens of icon suites, and
each icon suite is a handle).  In fact, if I have a window that is maxed
out (each window will hold a maximum amount of 50 icon suites), It would
seem that I would almost have to call MoreMasters() each time I
create/open a new window (when I create/open a new window, I perform a
NewHandle( sizeof(data_in_my_window) ) type of call in my program).  Is
there a call that REMOVES 64 master pointers?  In other words, I was
wondering if there is a way to call MoreMasters() before I create/open a
window, and call RemoveMastersFunction() after I close a window?  Yes, I
could just add another MoreMasters() call at the begining of my program,
but I intend to allow the user to have as many windows/files opened as
they want.

5) Is there a call that forces the system to compact the fragmented
memory of an app?  I
remember reading that the system automatically compacts the memory at
certain intervals, and I know that there are functions that will compact
the memory, so there is a certain amount of memory free (e.g.
CompactMem( x ), where x is the number of bytes needed), but is there a
call that will force the system to compact as much as possible?


+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 17 Oct 1994 12:10:17 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <37t4j9$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

>         DoAnimation(theDialog, step);
>         step++;
>         if(step >= 4)
>                 step = 0;
> }

Just a minor thing - I'll leave the memory management thing for others -
but if your PICTs are sequentially numbered, why not use the resource ID
directly, and savve yourself the switch statement? If they aren't
guaranteed to be sequential, you could still store them in an array which
would be easier to update than adding another case in the switch.

> void DoAnimation(DialogPtr theDialog, short step)
> {
>         PicHandle       pic;
>         Rect            r;
>
>
>         switch( step )
>         {
>                 case 0:
>                         pic = GetPicture(128);
>                         break;
>
>                 case 1:
>                         pic = GetPicture(129);
>                         break;

etc.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa        (at University of Cape Town 4 July-7 Nov)
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (MARK H. LINTON)
Date: 17 Oct 94 13:44:22 EST
Organization: HRB Systems, Inc.

In article <37t4j9$[e-mail]>, [e-mail] (Jeff Beeghly) writes:
>
> 1) ... Does StandardGetFile crash under low memory conditions?
>

        Sorry, don't know for sure, but I wouldn't be too
        surprised.

>
> 2) I am loading four separate pictures...
>

void DoAnimation(short step) {
    PicHandle    pic = GetPicture(128+step);

    if (pic != nil) DrawPicture(pic, &(**pic).portRect);
}

>
> Looks good so far, no?

        Well, no. I would guess this flashes like mad (but if you
        haven't gotten it to work yet, you wouldn't know that ;^).
        I would probably load the resources once, image them into
        offscreen graphics worlds and then just CopyBits in
        DoAnimation. Lots of sample code available to do this BTW.

> Well, the problem is that under a low memory condition (say ~7,000 -
> 8,000 bytes free), the first picture is loaded and displays fine, but
> when the second image is loaded, my app crashes...

        How do you know how much memory you have free?

>
> I then went in and added a
>     ReleaseResource( (Handle )pic);
> This time, each of the four pictures were loaded (and my app didn't crash)

        This should be a clue... (what has changed? why did that
        make a difference?... are your PICT resources marked
        purgeable?)

> ...but when the counter turned back to 0, the first pic wasn't displayed.
>
> I dismissed the dialog box and brought it back up again.  This time, none
> of the pictures were displayed!  Well, this leads me to believe that when
> I call ReleaseResource(), it not only frees up the memory of the handle
> holding the picture, but it clears it from the current resource as well.
> I then tried to use the DisposeHandle() call in place of the
> ReleaseResource() call, and the same thing occurred (all four pictures
> were displayed once and only once).
>
> At this point, I added following:
>
 if (pic != nil) {
       ...
 } else {
>     MoveTo(20, 20);
>     DrawString("\pCan't open image");
> }
>
> the error message never came up!
>
> So what gives?  I can't load and display the image, yet the pic isn't nil
> either!?!?!
>

        There were three statements in that last line.

        1) I can't load the image
        2) I can't display the image
        3) The handle to the image is not nil

        These can not all be true. GetPicture returns nil if it
        was unable to load the image. Since you say "the error
        message never came up" I will assume that 3 is true. This
        means that 1 must be false. This leaves only 2 as a
        problem for your application. This is what you must
        investigate.

        BTW, have you investigated how QuickDraw reports errors.
        Given that it appears that this "feature" is occurring in
        the DrawPicture call, how would you know that it failed?
        Apart from not being able to see the picture.

> Do I need to do a lot of watch dogging and not let any operations be
> performed if the app goes beneath 0k of memory is free?
>

        You have less than 0k of memory free and expect the
        program to do something?

        BTW, just to be a total smart-***, the generally accepted
        way to handle this type of situation is to:

        1) Figure out how much memory you application needs.
        2) Make sure that it gets at least that much.

        ;^) <--- note the smiley!

>
> 3) In Macintosh C Programming Primmer Vol 2, it states that when a
> program starts, it contains a block of master pointers.  It is within
> this location that the location of the Handles are kept (64 of them).  If
> the program requires more than 64, the MoreMasters() call needs to be
> made (which will create 64 more locations for handles).  What happens if
> I have filled up all 64 locations with handles, then create another
> handle (for arguments' sake, let's say that there is enough memory to
> create the size of the handle, and we create a new handle without
> calling MoreMasters())?  Will I run the risk of loosing the handle when
> memory is juggled around?
>

        If you call NewHandle, and you have no more master
        pointers available, NewHandle will call MoreMasters for
        you. The point behind doing it youself is that master
        pointer blocks are non-relocatable and tend to lead to
        heap fragmentation.

        If you let NewHandle make the call, the master pointer
        block will be placed as low in the heap as possible.
        Depending on what you have been doing, you may have
        relocatable or purgeable structures in heap below that
        block. If you want to reuse that memory, especially with
        something that may be larger than the things that
        previously occupied that space (as seems like you may) you
        are unable to because you have a master pointer block
        sitting where you need to put your new structure.

        Go ahead and call MoreMasters two, three... maybe ten
        times early in your program. Master pointer blocks are
        pretty small compared to the space you could loose letting
        NewHandle do it for you.

> 4) In my program, I manage multiple files at the same time (hence, my app
> manages several windows at the same time).  In each file/window, there
> are LOTS of different handles (my app displays dozens of icon suites, and
> each icon suite is a handle).  In fact, if I have a window that is maxed
> out (each window will hold a maximum amount of 50 icon suites), It would
> seem that I would almost have to call MoreMasters() each time I
> create/open a new window (when I create/open a new window, I perform a
> NewHandle( sizeof(data_in_my_window) ) type of call in my program).
>

        that would be a BadThing(r), see above.

>
> Is
> there a call that REMOVES 64 master pointers?  In other words, I was
> wondering if there is a way to call MoreMasters() before I create/open a
> window, and call RemoveMastersFunction() after I close a window?  Yes, I
> could just add another MoreMasters() call at the begining of my program,
> but I intend to allow the user to have as many windows/files opened as
> they want.
>

        no, again, see above

> 5) Is there a call that forces the system to compact the fragmented
> memory of an app?  I
> remember reading that the system automatically compacts the memory at
> certain intervals, and I know that there are functions that will compact
> the memory, so there is a certain amount of memory free (e.g.
> CompactMem( x ), where x is the number of bytes needed), but is there a
> call that will force the system to compact as much as possible?
>

        The memory manager has a number of calls in addition to
        CompactMem (FreeMem and PurgeMem come to mind) but these
        only help with relocatable and purgeable objects. If your
        memory is fragmented, it will stay fragmented, these calls
        only help you use the memory that you have left.

        From your literary reference above (an excellent starting
        point, I might add) I assume that you are (fairly) new to
        Macintosh programming, although from the apparent
        complexity of your application not to programming in
        general. Rather than answer you questions with answers, I
        will answer them with questions and refer you to further
        reading, so that you can learn the material yourself and
        not have to ask again next time.

        (new) Inside Macintosh: Memory - for references to
        questions about: MoreMasters, NewHandle, CompactMem,
        PurgeMem, FreeMem, etc.

        (new) Inside Macintosh: Imaging with QuickDraw - for
        references to questions about: DrawPicture, GetPicture,
        etc.

--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'märk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Beeghly)
Date: 18 Oct 1994 17:00:33 GMT
Organization: University of Washington

[e-mail] (MARK H. LINTON) writes:

>In article <37t4j9$[e-mail]>, [e-mail]
(Jeff Beeghly) writes:
>> 1) ... Does StandardGetFile crash under low memory conditions?
>        Sorry, don't know for sure, but I wouldn't be too
>        surprised.

I've received one reply that stated all standard system calls will most
likely crash when memory gets too low.  Therefore, in my app, if the
memory gets below 10k or 12k, I am going to inform the user that there is
not enough, and that they should close a file.


>>
>> 2) I am loading four separate pictures...
>>
>void DoAnimation(short step) {
>    PicHandle    pic = GetPicture(128+step);
>    if (pic != nil) DrawPicture(pic, &(**pic).portRect);
>}

>>
>> Looks good so far, no?

>        Well, no. I would guess this flashes like mad (but if you
>        haven't gotten it to work yet, you wouldn't know that ;^).
>        I would probably load the resources once, image them into
>        offscreen graphics worlds and then just CopyBits in
>        DoAnimation. Lots of sample code available to do this BTW.

Well, I guess you missed my point.  Yes, the function works
fine (if there is enough memory available).  For right now, I'm not
calling my animation at a set interval, so YES, obviously on faster CPUs it
will be 'FLASHED'.  Yes, I'm am going to put in a timer, so the interval is
standard from one machine to another.

I do know how to use CopyBits and off screen GWorlds.  For this portion
of the code, it is redundant.  Why?  I don't want to permanently 'hold'
the pictures... all I need is one picture drawn to the screen at a time
(therefore, I don't feel I need to hold all four).  Holding the bits in
an offscreen gworld would mean I am using twice the memory for the images:
one for the resource and one for the offscreen memory


>> Well, the problem is that under a low memory condition (say ~7,000 -
>> 8,000 bytes free), the first picture is loaded and displays fine, but
>> when the second image is loaded, my app crashes...

>        How do you know how much memory you have free?

There is a call called FreeMem() which I am using to output the free
memory.  I am also using a utility called SWATCH (System Watch) which
graphically & numerically displays the amount of locked used memory,
moveable used memory, and free memory each app is using.


>>
>> I then went in and added a
>>      ReleaseResource( (Handle )pic);
>> This time, each of the four pictures were loaded (and my app didn't crash)

>        This should be a clue... (what has changed? why did that
>        make a difference?... are your PICT resources marked
>        purgeable?)

Yes, it was a clue.  It was telling me that not only the handle was being
released, but the location of the resource was being released as well.
That is why I was only able to display each image once (and only once).
No, I was not marking the pictures within the resource as being
purgeable, but I am now doing HPurge( (Handle pic ) after the
DrawPicture call... it works..... better, but it still crashes (better in
the sence that if I set my app to run with ~ 12k free and call my dialog
it works, but if memory gets below 6k, it crashes... looks like I will
definately have to work on this a bit.

The point I was trying to make was this:

If I perform a DisposeHandle on a pic handle, how come I am not able to
load and display the picture a second time?  DisposeHandle should just
remove the handle, not the resouce, shouldn't it?

The other point I was trying to make was this:  If I can get the image
(and pic != nil), how come I am not able to display it?  If GetPicture
failed, it's supposed to return a 0, yet it doesn't, so what gives?


>>
>> At this point, I added following:
>>
> if (pic != nil) {
>       ...
> } else {
>>      MoveTo(20, 20);
>>      DrawString("\pCan't open image");
>> }
>>
>> the error message never came up!
>>
>> So what gives?  I can't load and display the image, yet the pic isn't nil
>> either!?!?!
>>

>        There were three statements in that last line.

>        1) I can't load the image
>        2) I can't display the image
>        3) The handle to the image is not nil

>        These can not all be true. GetPicture returns nil if it
>        was unable to load the image. Since you say "the error
>        message never came up" I will assume that 3 is true. This
>        means that 1 must be false. This leaves only 2 as a
>        problem for your application. This is what you must
>        investigate.

>        BTW, have you investigated how QuickDraw reports errors.
>        Given that it appears that this "feature" is occurring in
>        the DrawPicture call, how would you know that it failed?
>        Apart from not being able to see the picture.


Yes, I was a bit unclear.  The second time I get the picture, GetPicture
does not return a nil, yet I am unable to display the image.  I have THINK
Reference and it states that DrawPicture is a void, and it does not
indicate any error codes from DrawPicture.  I just looked up in my IM QD
book the QDError function.  I will use it for my app.  Thanks for the tip.


>> Do I need to do a lot of watch dogging and not let any operations be
>> performed if the app goes beneath 0k of memory is free?
>        You have less than 0k of memory free and expect the
>        program to do something?

That was a typo.  It should have been 10k free.

>        BTW, just to be a total smart-***, the generally accepted
>        way to handle this type of situation is to:

>        1) Figure out how much memory you application needs.
>        2) Make sure that it gets at least that much.

>        ;^) <--- note the smiley!

Yep.  Verry standard.  But the problem is this:  My app will handle an
unlimited number of files/windows (memory permitting).  I do not wish to
limit the user by only allowing them a max number of files open at a time
(like 5 or 10).  Each window/file at it's maximum will use ~ 55 handles
(I'm displaing a max of 50 icons, each is contained within an IconSuite,
which is a handle).  If I plan on having 5 files open, I should probably
call MoreMasters 4 times.  If I plan on having 10 files open, I should
probably call MoreMasters 9 times.

Get my point?

It's varriable depending on the user.  Ideally it would be nice to Call a
MoreMasters() call before I open a file, then do a DeleteMoreMasters call
(if such a call had existed) after I calosed a file.  These are all
design issues I will have to iron out I guess.


>>

>        If you call NewHandle, and you have no more master
>        pointers available, NewHandle will call MoreMasters for
>        you. The point behind doing it youself is that master
>        pointer blocks are non-relocatable and tend to lead to
>        heap fragmentation.

yep.

>        If you let NewHandle make the call, the master pointer
>        block will be placed as low in the heap as possible.
>        Depending on what you have been doing, you may have
>        relocatable or purgeable structures in heap below that
>        block. If you want to reuse that memory, especially with
>        something that may be larger than the things that
>        previously occupied that space (as seems like you may) you
>        are unable to because you have a master pointer block
>        sitting where you need to put your new structure.
yep
>        Go ahead and call MoreMasters two, three... maybe ten
>        times early in your program. Master pointer blocks are
>        pretty small compared to the space you could loose letting
>        NewHandle do it for you.

see above.


>        The memory manager has a number of calls in addition to
>        CompactMem (FreeMem and PurgeMem come to mind) but these
>        only help with relocatable and purgeable objects. If your
>        memory is fragmented, it will stay fragmented, these calls
>        only help you use the memory that you have left.

Yes, but for each of these call you need to specify an amount of space to try
to free up.  What I was wondering was if there was a call that causes the
system to compact ALL of the free memory.  From what I can tell, it
doesn't look like it.

>        From your literary reference above (an excellent starting
>        point, I might add) I assume that you are (fairly) new to
>        Macintosh programming, although from the apparent
>        complexity of your application not to programming in
>        general. Rather than answer you questions with answers, I
>        will answer them with questions and refer you to further
>        reading, so that you can learn the material yourself and
>        not have to ask again next time.

Pretty close.  I've been programming for several years and have
programmed several different operating systems (Unix, Atari ST/GEM,
Windows, now Mac).  I've been programming the Mac for ~ 6 months in my
spare time.  The biggest problems I have encountered w/the Mac are:

1 Unconventional.  I'm not taliking about event-driven programming
conceps, but things like string types.  Who the hell even USES Str63 or
Str255?!?!???  After years of honning my pointer & string skills, I have
to deal with this junk.  If I write my own function, I use pointers, if I
use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
a linked list on the Mac... I DARE YOU.

2 There are several good Mac programming books out there, but all only
cover the basics.  What I'd like to see is something that covers a full
scale real world type app.  One that covers such topics as Multiple
files/windows opened at a time, localization, printing, error-proofing
apps, etc...  I've seen some books that start to deal with some of these
topics, but don't go into very much depth on them.

3 Example code base is meeger.  There are several areas of Mac programming
which need some indepth examples.  The app which I'm writing shouldn't
have taken this long, but I got locked up on a couple topics.


>        (new) Inside Macintosh: Memory - for references to
>        questions about: MoreMasters, NewHandle, CompactMem,
>        PurgeMem, FreeMem, etc.

Don't have it, but I have THINK Reference.


>        (new) Inside Macintosh: Imaging with QuickDraw - for
>        references to questions about: DrawPicture, GetPicture,
>        etc.


Have it.

>--

>Hope this helps.


a little


Jeff



+++++++++++++++++++++++++++

>From [e-mail] (GBolsinga)
Date: 18 Oct 1994 17:41:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) writes:

>If I perform a DisposeHandle on a pic handle, how come I am not able to
>load and display the picture a second time?  DisposeHandle should just
>remove the handle, not the resouce, shouldn't it?

This is bad.  Use KillPicture for all PICTs that aren't resources.
Use ReleaseResource for all other PICTs.

Greg
MPI Multimedia


+++++++++++++++++++++++++++

>From [e-mail] (B.J. Buchalter)
Date: Tue, 18 Oct 1994 17:10:45 -0700
Organization: CSU Physics Department

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:


>
> I've received one reply that stated all standard system calls will most
> likely crash when memory gets too low.  Therefore, in my app, if the
> memory gets below 10k or 12k, I am going to inform the user that there is
> not enough, and that they should close a file.
>
>

Yes, this is important. Basically, your strategy needs to be that if the
amount of free memory gets to be too small (e.g. sufficently small that
operations WILL fail), you need to disable all of the commands that will
cause memory to be allocated. That is, if you don;t have enough memory for
the about box, disable the about box command. Similarly, if you are really
low on memory, don't allow the user to open another file, and perhaps ask
them to close one, or ask them to do something else that will free up
memory.


> If I perform a DisposeHandle on a pic handle, how come I am not able to
> load and display the picture a second time?  DisposeHandle should just
> remove the handle, not the resouce, shouldn't it?

You definitely do not want to use DisposeHandle on a resource. The
Resource Manager keeps a table of which resources are loaded and where
they are in memory. The Memory Manager keeps a table(s) of which handles
are allocated and where they are in memory. If you tell the resource
manager to release the resource it cleans up its table and marks the
resource purgable. If you tell the memory manager to Dispose the handle,
it frees the handle, but the resource manager still thinks that the handle
exists... bad news. If you make the resource purgable (HPurge), then
GetPicture will return the resource handle, even if the handle has been
purged. This means that you will get an empty PicHandle (if the available
memory is small enough). An empty PicHandle is a non-null handle that
points to a NULL value. This will cause quickdraw problems.

>
> The other point I was trying to make was this:  If I can get the image
> (and pic != nil), how come I am not able to display it?  If GetPicture
> failed, it's supposed to return a 0, yet it doesn't, so what gives?

See above about empty PicHandles. Also, even if you do get the picture,
there may not be enough memory available for the DrawPicture command to
complete. If the picture is simply a bitmap there is not too much overhead
in DrawPicture, but if there are any regions polygons, etc, DrawPicture
can require a reasonable amount of memory. What program did you use to
create the picture? SuperPaint, for example, stuffs a lot of crap into its
pictures, including PostScript dictionaries. If you really want to be safe
for low mem conditions, convert your picture into a bitmap or a pixmap,
and use copybits to image it. Even with copybits, the fact that it is not
interrupt safe probably means that you cannot rely on it not to use
memory.

Basically, the toolbox is not terribly stable under really low memory
conditions. It was generally written to assume that memory allocation will
not fail. It is your responsibility to ensure that the Toolbox has enough
memory to satisfy any allocations that it wants to make. In your case, you
have found that about 10-12K is required. You must ensure that the amount
of memory avaiable to the system never drops below this amount. Disable
commands if you must and explain to the user why these commands are
disabled.  It is better to not be able to do something than to have the
entire machine crash, especially if the function in question is simply
seeing the about box of the program.

If you want to get a little more sophisticated, read about growzone
functions in IM:Memory. This will allow you to set aside some 'emergency'
memory for those system calls that just cannot fail.

>
> Yes, I was a bit unclear.  The second time I get the picture, GetPicture
> does not return a nil, yet I am unable to display the image.  I have THINK
> Reference and it states that DrawPicture is a void, and it does not
> indicate any error codes from DrawPicture.  I just looked up in my IM QD
> book the QDError function.  I will use it for my app.  Thanks for the tip.
>
>

See above statments about empty handles and DrawPicture.

> >> Do I need to do a lot of watch dogging and not let any operations be
> >> performed if the app goes beneath 10k of memory is free?
> >        You have less than 10k of memory free and expect the
> >        program to do something?
>

Yes. But you should allow operations that increase the amount of free memory.


> Yep.  Verry standard.  But the problem is this:  My app will handle an
> unlimited number of files/windows (memory permitting).  I do not wish to
> limit the user by only allowing them a max number of files open at a time
> (like 5 or 10).  Each window/file at it's maximum will use ~ 55 handles
> (I'm displaing a max of 50 icons, each is contained within an IconSuite,
> which is a handle).  If I plan on having 5 files open, I should probably
> call MoreMasters 4 times.  If I plan on having 10 files open, I should
> probably call MoreMasters 9 times.
>
> Get my point?
>
> It's varriable depending on the user.  Ideally it would be nice to Call a
> MoreMasters() call before I open a file, then do a DeleteMoreMasters call
> (if such a call had existed) after I calosed a file.  These are all
> design issues I will have to iron out I guess.
>
>

There are a few things realed to this question. A master pointer block has
100 master pointers. The space for the pointers plus overhead is about 512
bytes (I think... don't remember exactly). You can get approx. 2 files per
master pointer block. If you initialize, say, 20 master pointer blocks,
that is only about 10k and it will allow approx. 40 windows before you
automagically get a new block. Probably OK (not many people can deal with
40 windows at once). Remeber, you need the master pointer blocks for other
types of handles also... not too much of a problem to have too many. Also,
will all of the icons in every window be different? 40 x 50 = 2000. I
would be really surprized if your app would actually have to show 2000
different icon suites (I could be wrong). You might look at sharing
handles for the common suites (This could be a big win).

If all of the above does not appeal, you can also look at generating new
heaps for each window (probably not a great solution).

But finally, fragmentation happens. You do everything you can to avoid it,
but there are parts of the toolbox that make it kind of difficult (if you
want to have no limits on your code). It is not the end of the world, just
something to be avoided. Especially if, as in your case, each window will
require approximately the same amount of space. If you have a memory map
like

   X
   P
   X <-
   X
   X
   X
   P
   P
   P
   P

where X = stuff for the window
and P = non-relocatable (e.g. Master pointer block)
if one window is closed (the one with the '<-', say) and another is
opened, then with what you have described, the new window ought to fit
into the memory occupied by the old window. In this case the fragmentation
does not affect you.

[stuff about memory management and MP blocks]

see above


> 1 Unconventional.  I'm not taliking about event-driven programming
> conceps, but things like string types.  Who the hell even USES Str63 or
> Str255?!?!???  After years of honning my pointer & string skills, I have
> to deal with this junk.  If I write my own function, I use pointers, if I
> use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
> a linked list on the Mac... I DARE YOU.

The Str63/Str255 is a legacy from pascal, and certain limits imposed from
the early design of the operating system (e.g. filename length limits).
They are generally not a problem (but I guess that I am used to them).

As far as linked lists goes.... use them all of the time. What is the problem?

> 3 Example code base is meeger.  There are several areas of Mac programming
> which need some indepth examples.  The app which I'm writing shouldn't
> have taken this long, but I got locked up on a couple topics.
>

Well, I guess that it is hard to make these claims if you don;t have
access to New Inside Macintosh. There are pretty good examples and
explanations of many of the issues you mention. Also, there is alot of
good source out on the net that essentially functions as sample code of
the type that you are looking for.

>
> >        (new) Inside Macintosh: Memory - for references to
> >        questions about: MoreMasters, NewHandle, CompactMem,
> >        PurgeMem, FreeMem, etc.
>
> Don't have it, but I have THINK Reference.
>

Think reference is not really a substitute.

Good luck, and don't let it get you down. It gets easier. Really.

B.J.

+++++++++++++++++++++++++++

>From Glenn L. Austin <[e-mail]>
Date: Wed, 19 Oct 1994 04:02:29 GMT
Organization: Eugene FreeNet

In article <380uvh$[e-mail]> Jeff Beeghly,
[e-mail] writes:
>Pretty close.  I've been programming for several years and have
>programmed several different operating systems (Unix, Atari ST/GEM,
>Windows, now Mac).  I've been programming the Mac for ~ 6 months in my
>spare time.

6 months is really not long enough to know the toolbox very well, but
certainly long enough to get a feel of what programming the Mac is like.
It's taken me 10 years to REALLY understand the guts of how the Macintosh
work -- and I was programming for 10 years prior to the Mac introduction
(mainframes, minis, micros).

In relation to your problem with the pictures, if the handle is NULL, the
resource didn't exist. If the first dereference of the handle is NULL,
there either wasn't enough memory to load the resource, or the resource
was purged.  If the first dereference is NULL, call LoadResource to see
if you can load it.  Code that I use for loading any handle looks like
this:

    Handle h = GetResource('XXXX', id);

    if (h)            // resource exists?
    {
        if (!*h)
            LoadResource(h);

        if (*h)
        {
            // use the resource
        }

        ReleaseResource(h);            // or HPurge(h) is even better!
    }

>The biggest problems I have encountered w/the Mac are:
>
>1 Unconventional.  I'm not taliking about event-driven programming
>conceps, but things like string types.  Who the hell even USES Str63 or
>Str255?!?!???  After years of honning my pointer & string skills, I have
>to deal with this junk.  If I write my own function, I use pointers, if I
>use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
>a linked list on the Mac... I DARE YOU.

No problem.  I use linked lists all the time.  Pointer AND Handles.

>2 There are several good Mac programming books out there, but all only
>cover the basics.  What I'd like to see is something that covers a full
>scale real world type app.  One that covers such topics as Multiple
>files/windows opened at a time, localization, printing, error-proofing
>apps, etc...  I've seen some books that start to deal with some of these
>topics, but don't go into very much depth on them.

I agree.  I've been thinking about that one for a while.  Especially
printing.  Printing is *EASY* on the Mac.  Try writing a simple printable
app for Windows -- what a NIGHTMARE!  For example, under Windows, you
have to do your own scaling (Move and Line are
device-resolution-specific, but Ellipse and such are based upon the
current scaling factor set).  I also found a major bug in printing
landscape (on an HP PCL printer) -- the same code which worked correctly
when printing portrait broke badly when printing landscape.  Items were
moved, portions of graphic items were drawn in different places on the
page (for example, half of an ellipse was drawn in one spot, the other
half was drawn in another spot, and there was white space between the two
halves!).  I ended up writing my own landscape code, and letting the
print drivers (plural -- each printer does its own print code) tell me
whether I should do my landscaping code.  That bug alone took two months
to find, diagnose and fix, because, although you can rotate text, many of
the parts of Windows GDI break down when dealing with vertical rather
than horizontal text.

>3 Example code base is meeger.  There are several areas of Mac
programming
>which need some indepth examples.  The app which I'm writing shouldn't
>have taken this long, but I got locked up on a couple topics.

I definately agree on this one, especially some of the newer managers!
However, many of the newer managers (that are extensive, like AOCE or
QDGX) have many example programs to search through to find the answers to
many questions.

However, it has been my experience that Windows programming examples are
even scarcer -- I had to find PD applications which addressed some of the
same issues I had to deal with!  Microsoft basically doesn't provide
anything easily accessable, and although Borland did provide some sample
code with their compiler, most of it had to do with the "bells &
whistles" of Windows, like OLE, MCI, and so forth, but very little on
standard "how to display a window contents and deal with scroll bars."  I
basically had to experiment with that until I got it right -- another two
months down the drain.

The same basic program that I wrote under Windows which took 12 months to
write and debug took 1 weekend (that's less than 40 hrs, folks!) to write
using Symantec C++ and TCL.  Much of the stuff I got for free on the
Macintosh.  Much of the stuff I had to write under Windows...
//
// Glenn L. Austin
// Computer Wizard and Racing Car Driver
// Internet:  [e-mail]
//

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 19 Oct 1994 17:25:21 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

<
<
< >> Do I need to do a lot of watch dogging and not let any operations be
< >> performed if the app goes beneath 0k of memory is free?
< >        You have less than 0k of memory free and expect the
< >        program to do something?
<
< That was a typo.  It should have been 10k free.
<
< >        BTW, just to be a total smart-***, the generally accepted
< >        way to handle this type of situation is to:
<
< >        1) Figure out how much memory you application needs.
< >        2) Make sure that it gets at least that much.
<
< >        ;^) <--- note the smiley!
<
< Yep.  Verry standard.  But the problem is this:  My app will handle an
< unlimited number of files/windows (memory permitting).  I do not wish to
< limit the user by only allowing them a max number of files open at a time
< (like 5 or 10).  Each window/file at it's maximum will use ~ 55 handles
< (I'm displaing a max of 50 icons, each is contained within an IconSuite,
< which is a handle).  If I plan on having 5 files open, I should probably
< call MoreMasters 4 times.  If I plan on having 10 files open, I should
< probably call MoreMasters 9 times.
<
< Get my point?
<
< It's varriable depending on the user.  Ideally it would be nice to Call a
< MoreMasters() call before I open a file, then do a DeleteMoreMasters call
< (if such a call had existed) after I calosed a file.  These are all
< design issues I will have to iron out I guess.
<
<

Most of the sample code I've seen uses a size of about 40K as the time to
post a low memory warning.  Since we're talking about 'Real World' apps
you should know that ALL real world apps have a growZone procedure and use
some mechanism for keeping a buffer of memory available.  Usually this
done by a mechanism known as the rainy-day fund.  Briefly, at app startup
you allocate a handle of, say, 40K.  That's your rainy day fund.  Each
time through your main event loop ( or perhaps only on null events) you
check the available memory.  If it's too low you post a warning alert.
Under some circumstances you release the rainy day handle.  Either from
your growZone Proc or possibly in response to an explicit call from
somewhere in your app.

Regarding the MoreMasters calls.  Exercise your app thoroughly with a
number of windows/documents open that is on the high side of what you
would consider avaerage.  See how many Master Pointer blocks were needed.
Maybe add 2 or 3 to this number and call MoreMasters this many times.
Eight or ten should be more than sufficient.  Realize that any user that
sees the 'not enough memory' warning is going to up the partition size for
the app.  Although this doesn't automatically increase the number of
Master Pointer blocks it does give the app more breathing room so that if
any are automatically allocated any problems caused by heap fragmentation
are minimized.  The important thing is to warn when memory gets low.


<   The biggest problems I have encountered w/the Mac are:
<
< 1 Unconventional.  I'm not taliking about event-driven programming
< conceps, but things like string types.  Who the hell even USES Str63 or
< Str255?!?!???  After years of honning my pointer & string skills, I have
< to deal with this junk.  If I write my own function, I use pointers, if I
< use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
< a linked list on the Mac... I DARE YOU.

Gee Jeff, we were just beginning to like you, and then you turn on us like
this:)  Are you aware that your windowlist is a linked list?  There are
numerous operating system queues that are linked lists.  Doing linked
lists with memory allocated by NewPtr or by malloc is no different than on
any other architecture.  You can do linked lists with handles.  The only
difference is an extra * here or there when referring to the memory
blocks.

If you're not aware, the reason for the Str255 and friends string types
are due to the Mac's Pascal heritage.  Don't complain about it, just
accept it.  Every development environment has utility routines to
translate between C and P strings.  Sorry you had to learn something new.

<
< 2 There are several good Mac programming books out there, but all only
< cover the basics.  What I'd like to see is something that covers a full
< scale real world type app.  One that covers such topics as Multiple
< files/windows opened at a time, localization, printing, error-proofing
< apps, etc...  I've seen some books that start to deal with some of these
< topics, but don't go into very much depth on them.
<
< 3 Example code base is meeger.  There are several areas of Mac programming
< which need some indepth examples.  The app which I'm writing shouldn't
< have taken this long, but I got locked up on a couple topics.

Are you aware of the sample code at ftp.apple.com and at the
alt.sources.mac archive at ftp://ftpbio.bgsu.edu/?

<
<
<
< Have it.
<
< >--
<
< >Hope this helps.
<
<
< a little
<
<
< Jeff

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 20 Oct 1994 04:00:28 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Brian Stern <[e-mail]> wrote:
>In article <380uvh$[e-mail]>, [e-mail]
>(Jeff Beeghly) wrote:
>
><
><
>< >> Do I need to do a lot of watch dogging and not let any operations be
>< >> performed if the app goes beneath 0k of memory is free?
>...
>< Get my point?

Get ZoneRanger and a color monitor. This is the *coolest* free program
for figuring out what the heck your app is doing in its memory
partition. It should be on any archive site and plenty of CDs.
Also, get ProcessWatcher, another free and useful tool.

>Most of the sample code I've seen uses a size of about 40K as the time to
>post a low memory warning.  Since we're talking about 'Real World' apps
>you should know that ALL real world apps have a growZone procedure and use
>some mechanism for keeping a buffer of memory available.  Usually this
>done by a mechanism known as the rainy-day fund.  Briefly, at app startup
>you allocate a handle of, say, 40K.  That's your rainy day fund.  Each
>time through your main event loop ( or perhaps only on null events) you
>check the available memory.  If it's too low you post a warning alert.
>Under some circumstances you release the rainy day handle.  Either from
>your growZone Proc or possibly in response to an explicit call from
>somewhere in your app.

I've abstracted and elaborated this. Each level in an app gets a
reserve memory. Then there's a memory cushion in addition. The app
sets the allocation level. The Toolbox level is the lowest, since the
TB can crash if it doesn't get memory. When I need to allocate memory,
I bump up the level, then restore it afterwards. For critical things,
like quitting and saving a file, I bump up the memory to a "critical"
level. Each level allows access to different memory reserves. The size
of the memory reserves for each level is set in a configuration
resource. The grow zone function runs a loop in which it frees up
reserves (depending on the current level) until enough bytes have been
freed. Memory warnings are issued depending on how much of the
reserves are depleted and how little memory is left. At each warning
level, the application can take different actions, e.g., at first just
an alert, then disabling functions like undo, then automatically
asking the user to close files, then automatically closing unmodified
files and saving modified files to temporary locations, and, finally,
terminating the application if all of the reserves are depleted and
there is very little memory left (e.g., less than 10K). I also have
code to automatically unload inactive segments, but it's not very
portable (works only with THINK C, not with Metrowerks).

>...
>< 1 Unconventional.  I'm not taliking about event-driven programming
>< conceps, but things like string types.  Who the hell even USES Str63 or
>< Str255?!?!???  After years of honning my pointer & string skills, I have
>< to deal with this junk.  If I write my own function, I use pointers, if I
>< use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
>< a linked list on the Mac... I DARE YOU.
>...
>If you're not aware, the reason for the Str255 and friends string types
>are due to the Mac's Pascal heritage.  Don't complain about it, just
>accept it.  Every development environment has utility routines to
>translate between C and P strings.  Sorry you had to learn something new.

I got tired of worrying about string types. At first, I just made a
rule that everything was a C string, and wrote wrappers around
offending toolbox routines. Then I decided it just didn't make sense
to worry about how long a string is, especially for variable length
things. So I wrote a string library that allocates everything
dynamically, and even replaces sprintf. This would have been easier
with C++, but hey, it works even with C. For string-intensive portions
of my code where many strings are used and where performance is
important, say parsing, I use direct pointers and allocate things from
a large chunk of memory or use a fixed string length. the string
library has functions for converting to and from regular C or Pascal
strings.

>< 3 Example code base is meeger.  There are several areas of Mac programming
>< which need some indepth examples.  The app which I'm writing shouldn't
>< have taken this long, but I got locked up on a couple topics.
>
>Are you aware of the sample code at ftp.apple.com and at the
>alt.sources.mac archive at ftp://ftpbio.bgsu.edu/?

Yup, I'd have to agree that there's tons of sample code. And there's
all the sample code that comes with your compiler (e.g., TC,
Metrowerks), and with Develop, etc.

--
"Ramsgate (n.) All institutional buildings must, by law, contain at
least twenty ramsgates. These are doors that open the opposite way to
the one you expect." -- D. Adams & J. Lloyd "The Meaning of Liff", p75.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 20 Oct 1994 04:25:35 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Ari I Halberstadt <[e-mail]> wrote:
>I've abstracted and elaborated this. Each level in an app gets a
>reserve memory. Then there's a memory cushion in addition. The app
>sets the allocation level. The Toolbox level is the lowest, since the
>TB can crash if it doesn't get memory. When I need to allocate memory,
>I bump up the level, then restore it afterwards. For critical things,
>like quitting and saving a file, I bump up the memory to a "critical"
>level. Each level allows access to different memory reserves. The size
>...

This paragraph is inconsistent. Basically, the Toolbox level has the
highest priority. The normal priority is the Toolbox level, since
there are so many TB calls that can allocate memory it's just easier
to keep it as the default. At the TB level, both my reserves and the
TB reserves can be accessed. When I allocate memory, I lower the
priority so as not to deplete the TB reserves, but I can still deplete
my reserves. This scheme can be extended to any number of levels
(which, in my case, is a bit necessary, since I have the TB, low-level
libraries, then the real application, each of which should have their
own reserves, even though my libraries aren't supposed to crash if
they run out of memory).
--
"Ramsgate (n.) All institutional buildings must, by law, contain at
least twenty ramsgates. These are doors that open the opposite way to
the one you expect." -- D. Adams & J. Lloyd "The Meaning of Liff", p75.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 20 Oct 1994 19:44:46 +0100
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

>< conceps, but things like string types.  Who the hell even USES Str63 or
>< Str255?!?!???  After years of honning my pointer & string skills, I have
>< to deal with this junk.  If I write my own function, I use pointers, if I
>< use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
>< a linked list on the Mac... I DARE YOU.

I use Str31, Str63 and Str255 where appropriate; mostly as
structure members and stack-based variables.

Anyone who knows enough C or C++ to program any computer for a
living (in those languages...) knows that when you have a
typedef:

typedef unsigned char Str31 [ 32 ] ;

what really gets passed to functions is a pointer to unsigned
char, so all functions should be declared as:

void
MyFunc (
    const unsigned char * source ,
    unsigned char * dest )


Similarly; you can pass an unsigned char pointer everywhere the
headers say "StrXXX"

Similarly for linked lists; use malloc() if you like it better,
or use NewPtr(). Or do a linked list with Handles; it's really
easy:

typedef struct elem {
    struct elem * * next ;
    long data ;
} elem , * elemPtr , * * elemHandle ;

elemHandle theList ;

void
insertelematend (
    long data )
{
    elemHandle theE = ( elemHandle ) NewHandle ( sizeof ( elem ) ) ;
    elemHandle * theP = & theList ;

    ( * theE ) -> next = NULL ;
    ( * theE ) -> data = data ;
    while ( * theP )
    {
        theP = & ( * theP ) -> next ;
    }
    * theP = theE ;
}


Cheers,

                / h+


--
  Jon Wätte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
   This is the kind of totally-gross-out-sick stuff you can do with C++ that
   makes the language kind of neat.
                                            -- Keith Rollin


+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Wed, 19 Oct 1994 01:22:44 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (B.J. Buchalter) wrote:

> Yes, this is important. Basically, your strategy needs to be that if the
> amount of free memory gets to be too small (e.g. sufficently small that
> operations WILL fail), you need to disable all of the commands that will

You also have to make sure that the amount of free memory doesn't get so
small that the user can't save documents, quit, etc.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 24 Oct 1994 19:52:54 -0800
Organization: Novell, Inc., Walnut Creek Macintosh Site

In article <380uvh$[e-mail]>,
[e-mail] (Jeff Beeghly) wrote:

> I've received one reply that stated all standard system calls will most
> likely crash when memory gets too low.  Therefore, in my app, if the
> memory gets below 10k or 12k, I am going to inform the user that there is
> not enough, and that they should close a file.

Try 33K. Why? Because 32K is the largest several of the more complicated
data structures in the Toolbox can be. Add 1K for super-emergencies and
you should be better off than using only 12K.

> The other point I was trying to make was this:  If I can get the image
> (and pic != nil), how come I am not able to display it?  If GetPicture
> failed, it's supposed to return a 0, yet it doesn't, so what gives?

Because the data in a 'PICT' is compressed. It gets expanded somewhat
during DrawPicture.

Also, consider skipping calls like GetPicture and simply using GetResource
directly. It provides an opportunity to do better error checking at the
price of the following difference in typing:

        PicHandle ph = GetPicture (128);

        PicHandle ph = (PicHandle) GetResource ('PICT',128);

Now you can call 'ResError' and find out all the other things which might
have gone wrong other than 'resNotFound'.

>The biggest problems I have encountered w/the Mac are:
>
> 1 Unconventional.  I'm not taliking about event-driven programming
> conceps, but things like string types.  Who the hell even USES Str63 or
> Str255?!?!???  After years of honning my pointer & string skills, I have
> to deal with this junk.  If I write my own function, I use pointers, if I
> use a toolbox call, well... I use  StrXXX.

I actually prefer Pascal strings for most operations because I always have
the length available without worrying about caching the result of
'strlen'. The fact that there are a zillion 'Str...' shouldn't faze you;
they're just Pascal strings with different maximum sizes. I use 'Str15',
for example, all the time for quick calls to 'NumToString'.

> And linked lists... try doing
> a linked list on the Mac... I DARE YOU.

I have. Other posters have pointed out that handles on the Macintosh are
not the same as handles on Windows. There's no more difficulty in writing
linked list code on the Mac than there is in typing an extra '*'. (It's
when people start trying to optimize the double-dereferencing that they
get into trouble.)

> 3 Example code base is meeger.  There are several areas of Mac programming
> which need some indepth examples.  The app which I'm writing shouldn't
> have taken this long, but I got locked up on a couple topics.

This is an odd observation, given that you appear to have "real" internet
access. Perhaps you are unaware of the many 'ftp' archive sites. There is
also copious example code on the various CD ROMs produced by Apple.

> >        (new) Inside Macintosh: Memory - for references to
> >        questions about: MoreMasters, NewHandle, CompactMem,
> >        PurgeMem, FreeMem, etc.
>
> Don't have it, but I have THINK Reference.

You absitively posolutely need to buy the relevant Inside Macintosh
volumes. They cost a lot of money. You need to buy them anyway.

--
 Views expressed here do not necessarily reflect the views of Novell.

---------------------------

>From [e-mail] (Peter Hull)
Subject: NewGWorld returns null pointer
Date: 20 Oct 1994 09:24:21 GMT
Organization: CRL Dialup Internet Access    [phone]  [Login: guest]

Hello,

I have a problem related to using GWorlds-- NewGWorld returns null in the
GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I already
have one document object open, identical to the one I am trying to create.
If I close the first document and then open a second one, everything is
cool.  But if I try to open a second document while the first is still open,
when my CGWorld object calls NewGWorld to create the offscreen world, it
gets this null pointer.  I am running the program in 4 megs of memory,
and the images are only 256x256 pixels.  (I'm using the Pico sample images
from 'develop' #10, from 'develop' CD #19.)

Does anybody have any idea why NewGWorld would return a null GWorld?  There's
nothing in Inside Macintosh that would suggest that NewGWorld might return
a null pointer except for the example code in NIM: "Imaging with QuickDraw",
chapter 6, which tests for a null pointer.  That is where I got the idea that
that might be the problem.  (Originally I thought the problem might be with
DrawPicture, because that's where the program froze.)

Any help would be appreciated...

Thanks in advance!

--
--
Peter Hull <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Peter Hull)
Date: 20 Oct 1994 21:18:34 GMT
Organization: CRL Dialup Internet Access    [phone]  [Login: guest]

Peter Hull ([e-mail]) wrote:
: Hello,

: I have a problem related to using GWorlds-- NewGWorld returns null in the
: GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I already
: have one document object open, identical to the one I am trying to create.
: If I close the first document and then open a second one, everything is
: cool.  But if I try to open a second document while the first is still open,
: when my CGWorld object calls NewGWorld to create the offscreen world, it
: gets this null pointer.  I am running the program in 4 megs of memory,
: and the images are only 256x256 pixels.  (I'm using the Pico sample images
: from 'develop' #10, from 'develop' CD #19.)

: Does anybody have any idea why NewGWorld would return a null GWorld?  There's
: nothing in Inside Macintosh that would suggest that NewGWorld might return
: a null pointer except for the example code in NIM: "Imaging with QuickDraw",
: chapter 6, which tests for a null pointer.  That is where I got the idea that
: that might be the problem.  (Originally I thought the problem might be with
: DrawPicture, because that's where the program froze.)

I now have discovered that the problem occurs also on the first document
object sometimes.  Why this is I still have no idea.  Here is the call,
straight from my source code:

    FailOSErr(anErr = NewGWorld(&itsWorld, depth,
                  &boundsRect, NULL, NULL, 0));

'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16.

After the call, sometimes 'itsWorld' is NULL.

However, I have never had an error show up in 'anErr'.
Any ideas?

--
--
Peter Hull <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 23 Oct 1994 18:07:12 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <386mra$[e-mail]>, [e-mail] (Peter Hull) wrote:

< Peter Hull ([e-mail]) wrote:
< : Hello,
<
< : I have a problem related to using GWorlds-- NewGWorld returns null in the
< : GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I already
<
<         FailOSErr(anErr = NewGWorld(&itsWorld, depth,
<                   &boundsRect, NULL, NULL, 0));
<
< 'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16.
<
< After the call, sometimes 'itsWorld' is NULL.
<
< However, I have never had an error show up in 'anErr'.
< Any ideas?
<
< --
< --
< Peter Hull <[e-mail]>

Actually this very question was posted a month or so back.  Are you
locking the object before making this call?  NewGWorld moves memory.  TCL
1.1.3 objects are handles.  If itsWorld is an instance varible and the
object is unlocked then NewGWorld will succeed but &itsWorld won't point
to the object anymore.  Either lock the object, or use a local varible for
the first parameter to NewGWorld and  then set itsWorld from the local
variable.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter Hull)
Date: 24 Oct 1994 10:16:33 GMT
Organization: CRL Dialup Internet Access    [phone]  [login: guest]

Regarding the GWorld problem with NewGWorld returning a null pointer,
Brian Stern's solution was correct.  He suggested that the problem was
being caused by NewGWorld moving memory while the object that called
it was unlocked in the heap.  This caused the (handle-based) object to
not receive the pointer correctly.  Here is my implementation of the fix:

HLock ((Handle) this);

<NewGWorld call here>

HUnlock ((Handle) this);

Depressingly simple, isn't it?  Many thanks to Brian and also to
Francois Pottier who e-mailed me with the same solution.

Cheers,

Peter

--

Peter Hull
<[e-mail]>

---------------------------

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Subject: Pathnames? I don't think so...
Date: Fri, 14 Oct 1994 17:36:29 -0700
Organization: Aladdin Systems

In article <[e-mail]>,
[e-mail] wrote:

> Not to answer the question, but to advance it to a different level, when you
> do a call to FindFolder (let's say to find the preferences folder on the
> startup volume) and you get a Folder ID, what is the most efficient way to
> convert it or utilize the information to be a path?
>
> Just another newbie,

OK. Here we go:
   On the mac, in general, you don't want to use pathnames. Users have
this distressing habit of moving files and renaming folders.

To open/rename/delete/etc a file:
   All the appropriate routines take a triplet:
      volume, directory ID, and file name.
In your example, you already have a volume refnum, and directory ID,
(from your call to FindFolder), and presumably you have the name.
   err = HOpen ( vrefNum, dirID, fName, fsRdWrPerm, &refNum );


To save the location of a file so you can find it later:
   Use the alias manager.

NewAlias (...);
later: ResolveAlias ( ... );

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


---------------------------

>From [e-mail] (Bob Bradley)
Subject: Q: Creating Variable sized structures?
Date: Sun, 16 Oct 1994 09:26:42 -0800
Organization: SS Software Inc.

How do you create variable sized structures, similar to how DITL resources
are used by the Dialog Manager?

Do they just create a handle and tack on things as they go? If so, it
would seem like they'd need some sort of index or they'd have to parse the
list each time to access individual items.

I'm writing a View-like library for creating Windows/Dialogs and I'm
looking for a good way to create variable sized structures that define the
details of the View but, having a tough time with this part of it.

Any comments appreciated.

+++++++++++++++++++++++++++

>From Eric Kidd <[e-mail]>
Date: 18 Oct 1994 03:00:39 GMT
Organization: Dartmouth College

Q: Creating Variable sized structures?

One easy way to do this is--if the variable part of the record is of
constant
size--is to define a struct like:

typedef struct
{
   // header info

   short index;
   element_type element[1];
} myType;

Reference data of this type with a handle and use the memory manager
(ResizeHandle? SizeHandle? I forget at the moment.) to resize it as you
need. You
could write a routine:

   ResizeMyType( myType** theData, short numSlots )

and call it as needed. Hope this helps. Any feedback appreciated.

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 18 Oct 1994 06:52:05 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Bob Bradley) wrote:

< How do you create variable sized structures, similar to how DITL resources
< are used by the Dialog Manager?
<
< Do they just create a handle and tack on things as they go? If so, it
< would seem like they'd need some sort of index or they'd have to parse the
< list each time to access individual items.
<
< I'm writing a View-like library for creating Windows/Dialogs and I'm
< looking for a good way to create variable sized structures that define the
< details of the View but, having a tough time with this part of it.
<
< Any comments appreciated.

Yes, variable-sized resources are built by allocating a handle and then
tacking things onto the end of it.  The routines like GetDItem, SetDItem,
and GetIndString walk down the resource each time to find the particular
item's data.  In general these data structures are small so that finding
the third or tenth item doesn't take very long.  Finding the hundreth or
thousandth item this way would be very slow.

Each of the items in these variable length data structures has a length
byte or short that is at a fixed offset from the beginning of each item
(often the offset is zero) to facilitate walking down the structure.  Also
the resource has an entry count in it, usually at the beginning.  Adding a
new item at the end is just a matter of using PtrAndHand and then updating
the item counter.  Modifying existing items or inserting items in the
middle is a matter of adjusting the size of the handle and blockmove to
make space in the middle, followed by blockmove to insert the new data.

My personal favorite is the Speech Manager 'dict' resource.  In this
perverse resource there is a header, followed by a variable length array
of variable length records.  Each of these last records consists of two
(or more) variable length records.  Sort of like an array of STR#
resources.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 18 Oct 1994 16:51:27 GMT
Organization: UCLA, Computer Science Department

In article <37vdon$[e-mail]> Eric Kidd <[e-mail]> writes:
>Q: Creating Variable sized structures?
>
>One easy way to do this is--if the variable part of the record is of
>constant
>size--is to define a struct like:
>
>typedef struct
>{
>   // header info
>
>   short index;
>   element_type element[1];
>} myType;

In THINK C (don't know about CW) it is legal to declare an array of unspecified
size (e.g. "element_type element[];") which will not contribute to the size of
the struct. Then allocation of the handle becomes:

  Handle  theHandle;
  Size    elementCount = kDefaultElementCount; // The number of array elements

  theHandle = NewHandle(sizeof(myType) + sizeof(element_type) * elementCount);

IMHO this is easier than having to remember that you get one element for free
in sizeof(myType).

>Reference data of this type with a handle and use the memory manager
>(ResizeHandle? SizeHandle? I forget at the moment.) to resize it as you
>need. You could write a routine:

That would be SetHandleSize();

All of the routines dealing with handles are documented in Inside Macintosh:
Memory.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
Death to the Trojans! Go Bruins!

(Insert disclaimer here)
Internet: [e-mail]

---------------------------

>From [e-mail] (Barend Kobben)
Subject: QuickTime + MIDI?
Date: Tue, 11 Oct 1994 15:45:13 GMT
Organization: Cartography dept., Utrecht University

Hi,

REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
Musical Instruments" extension, you have the ability to handle MIDI-files.
When openening these Midi files with a QuickTime player (like MoviePlayer,
PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie
(Sound only, of course).
Even better is the ability (under the Options... button) to fiddle around
with the instruments.
This means that the MIDI instruments (made by Roland, if you believe the
About... button) are there, a samples, inside these extensions!

QUESTION: Is there a description of this: How is it formatted, how can I
handle this from inside my programs?

--
Barend Kobben ([e-mail])
Cartography Dept., Utrecht University
PO Box 80115, 3508 TC Utrecht, The Netherlands
tel [phone]; fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sun, 16 Oct 1994 13:18:45 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Barend Kobben) wrote:

> Hi,
>
> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
> Musical Instruments" extension, you have the ability to handle MIDI-files.
> When openening these Midi files with a QuickTime player (like MoviePlayer,
> PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie
> (Sound only, of course).
> Even better is the ability (under the Options... button) to fiddle around
> with the instruments.
> This means that the MIDI instruments (made by Roland, if you believe the
> About... button) are there, a samples, inside these extensions!

Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD.

> QUESTION: Is there a description of this: How is it formatted, how can I
> handle this from inside my programs?

This documentation will be released in the forthcoming SDK CD (2.0 final),
as for final dates, sorry I don't have the data.

Cheers, KEnt

--
Kent Sandvik    [e-mail]            New Media Analyst/Programmer
Private activities on the net not sponsored by the company I work for.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 17 Oct 94 16:06:59 +1300
Organization: University of Waikato, Hamilton, New Zealand

(sorry for the previous failures, our News system ran out of room...)

In article <sandvik-1610941318450001@17.255.38.231>, [e-mail] (Kent San
dvik) writes:
> In article <[e-mail]>,
> [e-mail] (Barend Kobben) wrote:
>
>> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
>> Musical Instruments" extension, you have the ability to handle MIDI-files.
>> When openening these Midi files with a QuickTime player (like MoviePlayer,
>> PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie
>> (Sound only, of course).
>> Even better is the ability (under the Options... button) to fiddle around
>> with the instruments.
>> This means that the MIDI instruments (made by Roland, if you believe the
>> About... button) are there, a samples, inside these extensions!
>
> Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD.

No you don't! I was trying this out over the weekend, with MoviePlayer 1.0.
The MIDI files were off the CD-ROM that came with the July issue of "Future
Music" magazine. I copied them to my hard disk, set their type to "Midi", and
then did an "Open..." from within MoviePlayer. Sure enough, they showed up,
and I was able to convert them.

Just one problem: I had to click the "Options..." button before each file would
convert properly. If I didn't, I got a garbage movie. Just bringing up the
options dialog and clicking "Cancel" to go back to the save dialog was enough.

By the way, the options dialog is fun: you get to see all the instruments that
are installed, and there's a little keyboard so you can try them out!

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From jim [e-mail] (Jim Reekes)
Date: Mon, 17 Oct 1994 22:30:03 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

> (sorry for the previous failures, our News system ran out of room...)
>
> In article <sandvik-1610941318450001@17.255.38.231>, [e-mail]
(Kent San
> dvik) writes:
> > In article <[e-mail]>,
> > [e-mail] (Barend Kobben) wrote:
> >
> >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
> >> Musical Instruments" extension, you have the ability to handle MIDI-files.
> >> When openening these Midi files with a QuickTime player (like MoviePlayer,
> >> PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie
> >> (Sound only, of course).
> >> Even better is the ability (under the Options... button) to fiddle around
> >> with the instruments.
> >> This means that the MIDI instruments (made by Roland, if you believe the
> >> About... button) are there, a samples, inside these extensions!
> >
> > Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD.
>
> No you don't! I was trying this out over the weekend, with MoviePlayer 1.0.
> The MIDI files were off the CD-ROM that came with the July issue of "Future
> Music" magazine. I copied them to my hard disk, set their type to "Midi", and
> then did an "Open..." from within MoviePlayer. Sure enough, they showed up,
> and I was able to convert them.
>
> Just one problem: I had to click the "Options..." button before each
file would
> convert properly. If I didn't, I got a garbage movie. Just bringing up the
> options dialog and clicking "Cancel" to go back to the save dialog was enough.
>
> By the way, the options dialog is fun: you get to see all the instruments that
> are installed, and there's a little keyboard so you can try them out!

The file type needs to be set to 'Midi' and then you import them. But
there's a bug and they may get imported as type TEXT. So you get a movie
with a TEXT track and not a Midi track. The workaround, as Lawrence has
found, is to first click the Options button. Then the Import will work.

You only need the new and un-tested version of MoviePlayer to change the
instruments *after* importing the Midi file to a movie.

- ---------------------------------------------------------------------
Jim Reekes, Polterzeitgeist   |     Macintosh Toolbox Engineering
                              |          Sound Manager Expert
Apple Computer, Inc.          | "All opinions expressed are mine, and do
2 Infinite Loop  MS 302-3KS   |   not necessarily represent those of my
Cupertino, CA 95014           |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

>From [e-mail]
Date: 18 Oct 94 12:15:06 MST
Organization: (none)

In article <[e-mail]>, jim [e-mail] (Jim Reekes) writes:
> In article <[e-mail]>, [e-mail]
> (Lawrence D'Oliveiro, Waikato University) wrote:
>
>> (sorry for the previous failures, our News system ran out of room...)
>>
>> In article <sandvik-1610941318450001@17.255.38.231>, [e-mail]
> (Kent San
>> dvik) writes:
>> > In article <[e-mail]>,
>> > [e-mail] (Barend Kobben) wrote:
>> >
>> >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
>> >> Musical Instruments" extension, you have the ability to handle MIDI-files.
>> >> When openening these Midi files with a QuickTime player (like MoviePlayer,

[mucho snipto]

>>
>> Just one problem: I had to click the "Options..." button before each
> file would
>> convert properly. If I didn't, I got a garbage movie. Just bringing up the
>> options dialog and clicking "Cancel" to go back to the save dialog was enough.
>>
>> By the way, the options dialog is fun: you get to see all the instruments that
>> are installed, and there's a little keyboard so you can try them out!
>
> The file type needs to be set to 'Midi' and then you import them. But
> there's a bug and they may get imported as type TEXT. So you get a movie
> with a TEXT track and not a Midi track. The workaround, as Lawrence has
> found, is to first click the Options button. Then the Import will work.
>
> You only need the new and un-tested version of MoviePlayer to change the
> instruments *after* importing the Midi file to a movie.
>


ON a related question: I know that QT 2.0 has MPEG capabilities also. WHile
I'm aware that there's no software-based decompressor, I noticed that when I
tried to open a .mpg file off of the SIGGRAPH CD, the latest Movie Player gave
me the "CONVERT" button, just like when one converts a sound-track off of an
audio CD.

Unfortunately, it wouldn't actually do anything, saying "this is not a movie."

Is this a feature that wasn't completely implemented, or am I not completing
the process correctly?


Thanks in advance.


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Paul C. H. Ho)
Date: Wed, 19 Oct 1994 14:42:33 -0500
Organization: Pink Elephant Technologies

In article <[e-mail]>, jim
[e-mail] (Jim Reekes) wrote:

> In article <[e-mail]>, [e-mail]
> (Lawrence D'Oliveiro, Waikato University) wrote:
>
> > (sorry for the previous failures, our News system ran out of room...)
> >
> > In article <sandvik-1610941318450001@17.255.38.231>, [e-mail]
> (Kent San
> > dvik) writes:
> > >
> > > Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD.
> >
> > No you don't! I was trying this out over the weekend, with MoviePlayer 1.0.
> > The MIDI files were off the CD-ROM that came with the July issue of "Future
> > Music" magazine. I copied them to my hard disk, set their type to
"Midi", and
> > then did an "Open..." from within MoviePlayer. Sure enough, they showed up,
> > and I was able to convert them.
> >
> > Just one problem: I had to click the "Options..." button before each
> file would
> > convert properly. If I didn't, I got a garbage movie. Just bringing up the
> > options dialog and clicking "Cancel" to go back to the save dialog was
enough.
> >
> > By the way, the options dialog is fun: you get to see all the
instruments that
> > are installed, and there's a little keyboard so you can try them out!
>
> The file type needs to be set to 'Midi' and then you import them. But
> there's a bug and they may get imported as type TEXT. So you get a movie
> with a TEXT track and not a Midi track. The workaround, as Lawrence has
> found, is to first click the Options button. Then the Import will work.

I wrote a freeware program All Midi to do this in batch. Just drag and drop
(based on DropShell 2.0), no need to change file type or click the Options
button. All Midi will automatically skip all non-midi file, so you can just
drop in a folder. I side step the bug by using Movie Data Exchange directly.

> You only need the new and un-tested version of MoviePlayer to change the
> instruments *after* importing the Midi file to a movie.

For the rest of us, download my shareware QuickMovie to change the
instruments after importing the Midi. It's in beta...

I wrote four QT midi programs with no document at all (except the header files
that come with CW4). Any comment or suggestion on my midi stuff are welcome.
ftp://sumex-aim.stanford.edu/info-mac/grf/util/desktop-tv-120.hqx
ftp://sumex-aim.stanford.edu/info-mac/grf/util/screen-movie-110.hqx
ftp://sumex-aim.stanford.edu/info-mac/grf/util/quick-movie-10b2.hqx
ftp://sumex-aim.stanford.edu/info-mac/snd/util/all-midi-10.hqx

DesktopTV and ScreenMovie can record MIDI sequence and connect
your MIDI keyboard to QT2.0 music instruments via MIDI manager.

BTW, where can I find QuickTimeLib for QT 2.0. I can't link quick-movie with
the PPC compiler.

> -----------------------------------------------------------------------
> Jim Reekes, Polterzeitgeist   |     Macintosh Toolbox Engineering
>                               |          Sound Manager Expert
> Apple Computer, Inc.          | "All opinions expressed are mine, and do
> 2 Infinite Loop  MS 302-3KS   |   not necessarily represent those of my
> Cupertino, CA 95014           |       employer, Apple Computer Inc."

Paul C.H. Ho
Pink Elephant Technologies
[e-mail]
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Paul C. H. Ho)
Date: Thu, 20 Oct 1994 09:03:13 -0500
Organization: Pink Elephant Technologies

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>, jim
[e-mail] (Jim Reekes) writes:
> > In article <[e-mail]>, [e-mail]
> > (Lawrence D'Oliveiro, Waikato University) wrote:
> >
> >> (sorry for the previous failures, our News system ran out of room...)
> >>
> >> In article <sandvik-1610941318450001@17.255.38.231>, [e-mail]
> > (Kent San
> >> dvik) writes:
> >> > In article <[e-mail]>,
> >> > [e-mail] (Barend Kobben) wrote:
> >> >
> >> >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime
> >> >> Musical Instruments" extension, you have the ability to handle
MIDI-files.
> >> >> When openening these Midi files with a QuickTime player (like
MoviePlayer,
>
> [mucho snipto]
>
> >>
> >> Just one problem: I had to click the "Options..." button before each
> > file would
> >> convert properly. If I didn't, I got a garbage movie. Just bringing up the
> >> options dialog and clicking "Cancel" to go back to the save dialog
was enough.
> >>
> >> By the way, the options dialog is fun: you get to see all the
instruments that
> >> are installed, and there's a little keyboard so you can try them out!
> >
> > The file type needs to be set to 'Midi' and then you import them. But
> > there's a bug and they may get imported as type TEXT. So you get a movie
> > with a TEXT track and not a Midi track. The workaround, as Lawrence has
> > found, is to first click the Options button. Then the Import will work.
> >
> > You only need the new and un-tested version of MoviePlayer to change the
> > instruments *after* importing the Midi file to a movie.
> >
>
>
> ON a related question: I know that QT 2.0 has MPEG capabilities also. WHile
> I'm aware that there's no software-based decompressor, I noticed that when I
> tried to open a .mpg file off of the SIGGRAPH CD, the latest Movie
Player gave
> me the "CONVERT" button, just like when one converts a sound-track off of an
> audio CD.
>
> Unfortunately, it wouldn't actually do anything, saying "this is not a movie."
>
> Is this a feature that wasn't completely implemented, or am I not completing
> the process correctly?

It seem QT 2.0 come with 2 MPEG import components and a MPEG media handler
but don't have any MPEG codec. That's why it try to import with the 'eat '
component
and then run into problem later...

> Thanks in advance.
>
>
> Lawson
Paul C. H. Ho
Pink Elephant Technologies
[e-mail]
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 22 Oct 1994 16:07:14 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:
> No you don't! I was trying this out over the weekend, with MoviePlayer 1.0.
> The MIDI files were off the CD-ROM that came with the July issue of "Future
> Music" magazine. I copied them to my hard disk, set their type to "Midi", and
> then did an "Open..." from within MoviePlayer. Sure enough, they showed up,
> and I was able to convert them.

Oh, the wonders of the Component Manager. I stand corrected.

--Kent

--
Kent Sandvik    [e-mail]            New Media Analyst/Programmer
Private activities on the net not sponsored by the company I work for.

---------------------------

>From [e-mail] (Eric Bennett)
Subject: Software volume locking: HELP!
Date: 18 Oct 1994 15:32:10 GMT
Organization: Penn State University

I have successfully used PBSetVInfo to software-lock a volume as
described in Inside Mac: Files on page 2-147, which deals with
PBSetVInfo (call PBGetVInfo, set bit 15 of the ioVAtrb field, and call
PBSetVInfo).  The only problem is that I cannot UNLOCK these volumes
using the same method (this time clearing bit 15)--I get the error
"volume locked" (error -43, I think). Yes, the volume is locked, but
shouldn't the command which can set the lock be able to unlock it?
What toolbox call CAN I use to unlock a software-locked volume?

Thanks,
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pasha Sadri)
Date: Tue, 18 Oct 1994 16:50:22 -0800
Organization: ucsd

In article <380ppq$[e-mail]>, [e-mail]
(Eric Bennett) wrote:

 Yes, the volume is locked, but
> shouldn't the command which can set the lock be able to unlock it?
> What toolbox call CAN I use to unlock a software-locked volume?

hi,

Apparantly not. I think you need to clear the bit manually using something
like Norton Disk Editor. I don't know how exactly but there was a post
sometime ago about how to do this.

I know this isn't much help, but at least you won't try that again and
know what to look for. : )

Pasha Sadri
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Bennett)
Date: 19 Oct 1994 00:59:54 GMT
Organization: Penn State University

In article <[e-mail]>
[e-mail] (Pasha Sadri) writes:

> In article <380ppq$[e-mail]>, [e-mail]
> (Eric Bennett) wrote:
>
>  Yes, the volume is locked, but
> > shouldn't the command which can set the lock be able to unlock it?
> > What toolbox call CAN I use to unlock a software-locked volume?
>
> hi,
>
> Apparantly not. I think you need to clear the bit manually using something
> like Norton Disk Editor. I don't know how exactly but there was a post
> sometime ago about how to do this.
>
> I know this isn't much help, but at least you won't try that again and
> know what to look for. : )
>

I know how to clear the bit with Norton Disk Editor--don't worry, I
haven't
done any damage to myself.  But clearing the bit with NDE seems like a
very non-Mac way of doing things.  I'm sure that there has to be a
toolbox
call that will do this--I just have no idea what it is (alternatively,
writing directly to the disk from within my program as NDE does ought
to
work, but I don't want to do that--I want to use a standard and SAFE
toolbox
call.

[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (LEBRA olivier)
Date: 19 Oct 1994 16:05:00 GMT
Organization: Dept. of Computer Science, Concordia University

In article <380ppq$[e-mail]>, [e-mail] (Eric Bennett) writes:
|> I have successfully used PBSetVInfo to software-lock a volume as
|> described in Inside Mac: Files on page 2-147, which deals with
|> PBSetVInfo (call PBGetVInfo, set bit 15 of the ioVAtrb field, and call
|> PBSetVInfo).  The only problem is that I cannot UNLOCK these volumes
|> using the same method (this time clearing bit 15)--I get the error
|> "volume locked" (error -43, I think). Yes, the volume is locked, but
|> shouldn't the command which can set the lock be able to unlock it?
|> What toolbox call CAN I use to unlock a software-locked volume?
|>
|> Thanks,
|> [e-mail]



I will help you !
I have made a soft called DiskLocker that made what you want.
Before unlocking the disk with PBSetVInfo, you must update a global variable
used by the Finder. I do not remember its name and its structure but I will
check at home and I will reply to you again soon.


olivier lebra      [e-mail]  or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Bryan)
Date: Fri, 21 Oct 1994 06:24:29 GMT
Organization: Sexton Software

> In article <380ppq$[e-mail]>, [e-mail]
> (Eric Bennett) wrote:
>
>  Yes, the volume is locked, but
> > shouldn't the command which can set the lock be able to unlock it?
> > What toolbox call CAN I use to unlock a software-locked volume?
>

I don't know if you already have the response but the trick is to update
the vcb queue elem before making the unlock toolbox call. You can get the
vcb queue elem either by "walking the vcb queue" and setting the
appropriate bit in place (I think it is one of the bits in the attribute
field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This
strategy worked for a little control panel I wrote many years ago (ie the
source code is not handy). Good luck.

--
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (LEBRA olivier)
Date: 21 Oct 1994 19:08:39 GMT
Organization: Dept. of Computer Science, Concordia University

In article <[e-mail]>, [e-mail] (Steve Bryan) writes:
|> > In article <380ppq$[e-mail]>, [e-mail]
|> > (Eric Bennett) wrote:
|> >
|> >  Yes, the volume is locked, but
|> > > shouldn't the command which can set the lock be able to unlock it?
|> > > What toolbox call CAN I use to unlock a software-locked volume?
|> >
|>
|> I don't know if you already have the response but the trick is to update
|> the vcb queue elem before making the unlock toolbox call. You can get the
|> vcb queue elem either by "walking the vcb queue" and setting the
|> appropriate bit in place (I think it is one of the bits in the attribute
|> field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This
|> strategy worked for a little control panel I wrote many years ago (ie the
|> source code is not handy). Good luck.
|>
|> --
|> Steve Bryan                  InterNet: [e-mail]
|> Sexton Software            CompuServe: 76545,527
|> Minneapolis, MN                   Fax: [phone]


I think the simplest way to update the vcb queue is :
DefVCBPtr->vcbAtrb &= 0x7FFF;


--
*********************************************************************
*        olivier       * Until July 1996 : [e-mail] *
*         lebra        * Until May 1995  : [e-mail]    *
*********************************************************************
* 1950, Lincoln  App #1707  -  H3H 2N8  Montreal, Quebec  -  CANADA *
* Phone : [phone]                                         *
*********************************************************************
*     "La simplicite est l'ultime forme de la sophistication."      *
*********************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Eric Bennett)
Date: 24 Oct 1994 16:18:11 GMT
Organization: Penn State University

In article <[e-mail]>
[e-mail] (Kluev) writes:

> Try clear locked flag of vcbAtrb field of VCB describing volume.
> You can find VCB using GetVCBQHdr call and stepping via dLink
> field until you find the volume. This method, however, should
> be treated as modifying internal File Manager structures and
> should be avoided if possible.

I know--Inside Mac says DON'T PLAY WITH THE VCB--it is supposed to be
read only, not written to.  My question was, if I'm not supposed to
modify the VCB, how do I unlock the volume?  (Incidentally, when I
tried modifying the VCB, my machine locked up; however, since that's
the only suggestion I've gotten, I guess I'll try doing it again :).

[e-mail]

---------------------------

>From [e-mail] (Anton Rang)
Subject: Some string routines for the PowerPC
Date: 15 Oct 1994 21:29:50 GMT
Organization: Trillium Research, Inc.

Archive-name: ppc-string-utils.txt
Submitted-by: [e-mail]

This file implements some basic string routines for both C and Pascal
strings.  It's written in PowerPC assembly.  I did this mainly as a
learning experience; I was bored one day, and wanted to play with the
string instructions.

Routines implemented here are:

  strcpy and strcat -- both of these are about 30% faster than those
               provided by Apple or Metrowerks.

  pstrcpy and pstrcat -- very fast versions of the above for use with
             Pascal-style strings; much faster than those
             provided by Apple (PLstrcpy/PLstrcat).

  pstreq -- a fast equality test for Pascal-style strings.

If there's interest, I may develop and post more of these later.

I've appended a binhexed object library for those without an assembler.

An open question: Is there interest in developing a complete, or at
least subset, copyright-free, optimized, ANSI library for the PowerPC?
I see people complaining about Metrowerks' implementation, and neither
Metrowerks nor Apple has so far released a highly optimized library.
I'd rather see them concentrating on compiler technology, anyway.  If
there's enough interest, surely those of us on the net could compile a
reasonably complete library.  This would surely benefit all of the Mac
community.

  -- Anton

- -------- mylib.s
;
; Anton's library of handy string routines and such.
;

;
; char *strcpy(char *, const char *)
;
; Copy a null-terminated string from one location to another; return the first location.
; This goes really fast if you use the POWER 'lscbx' instruction.  *sigh*
;

        export  my_strcpy[DS]
        export  .my_strcpy[PR]

        toc
            tc  my_strcpy[TC], my_strcpy[DS]

        csect   my_strcpy[DS]
            dc.l    .my_strcpy[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .my_strcpy[PR]

        ; First, move R3 into R5, so we have a copy we can change.  Bias it down by one byte.
        ; Bias R4 down too.

        subi    r5, r3, 1
        subi    r4, r4, 1

        ; Read a byte, store it, and compare it against zero.  Loop until we find the zero.
        ; By issuing the compare before the store, we save one cycle in branch resolution.

@0:     lbzu    r0, 1(r4)
        cmpwi   r0, 0
        stbu    r0, 1(r5)
        bne     @0

        ; All done.  Note that R3 has the return value already.

        blr

;
; void pstrcpy(unsigned char *, const unsigned char *)
;
; Copy a byte-counted string from one location to another.
;

        export  pstrcpy[DS]
        export  .pstrcpy[PR]

        toc
            tc  pstrcpy[TC], pstrcpy[DS]

        csect   pstrcpy[DS]
            dc.l    .pstrcpy[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcpy[PR]

        ; Get the byte count, and add one to it to include the length byte.

        lbz     r5, 0(r4)
        addi    r5, r5, 1

        ; If the length is <= 32, we can complete the move in one pass.  We assume that this
        ; is the most common case, and hence set the branch-predict bit here.
        ; (Why 32 bytes?  We have 8 non-volatile scratch registers, R5..R12, to use.)

@0:     cmpwi   r5, 32
        ble+    @1

        ; OK...more than 32 bytes to move.  We'll move 28 bytes and then see if we can finish.
        ; (Why 28 bytes?  We're holding the length in R5, so we only have 7 scratch registers.)

        subi    r5, r5, 28

        lswi    r6, r4, 28
        addi    r4, r4, 28

        stswi   r6, r3, 28
        addi    r3, r3, 28

        b       @0

        ; We complete the move here, mov    b       @0

        ; We complete the move here, moving between 1 and 32 bytes.

@1:     mtxer   r5

        lswx    r5, r0, r4
        stswx   r5, r0, r3

        blr

;
; char *strcat(char *, const char *)
;
; Concatenate a null-terminated string onto another; return the address of the first string.
;

        export  my_strcat[DS]
        export  .my_strcat[PR]

        toc
            tc  my_strcat[TC], my_strcat[DS]

        csect   my_strcat[DS]
            dc.l    .my_strcat[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .my_strcat[PR]

        ; First, move R3 into R5, so we have a copy we can change.  Bias it down by one byte.
        ; Bias R4 down too.

        subi    r5, r3, 1
        subi    r4, r4, 1

        ; Walk down the first string to its end.

@0:     lbzu    r0, 1(r5)
        cmpwi   r0, 0
        bne     @0

        ; R5 is now one byte past the end of the string.  Go backwards to bytes, so that
        ; it points just before the end of the string.

        subi    r5, r5, 2

        ; Read a byte, store it, and compare it against zero.  Loop until we find the zero.
        ; By issuing the compare before the store, we save one cycle in branch resolution.

@1:     lbzu    r0, 1(r4)
        cmpwi   r0, 0
        stbu    r0, 1(r5)
        bne     @1

        ; All done.  Note that R3 has the return value already.

        blr

;
; void pstrcat(unsigned char *, const unsigned char *)
;
; Concatenate a byte-counted string onto another.  This doesn't do any error checking.
;

        export  pstrcat[DS]
        export  .pstrcat[PR]

        toc
            tc  pstrcat[TC], pstrcat[DS]

        csect   pstrcat[DS]
            dc.l    .pstrcat[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcat[PR]

        ; Get the byte count of both strings.

        lbz     r6, 0(r3)
        lbz     r5, 0(r4)

        ; Note that lswx/stswx are defined to do nothing if the length (in XER) is zero.
        ; If they weren't, we would want the following two lines, to check that the
        ; concatenation is actually doing something.

        ; cmpwi r5, 0
        ; beqlr

        ; Add them together to get the new length; store it.

        add     r7, r6, r5
        stb     r7, 0(r3)

        ; Move destination address past old data (length + 1 bytes).
        ; Move source address past its length too (1 byte).

        addi    r3, r3, 1
        addi    r4, r4, 1
        add     r3, r3, r6

        ; If the length is <= 32, we can complete the move in one pass.  We assume that this
        ; is the most common case, and hence set the branch-predict bit here.
        ; (Why 32 bytes?  We have 8 non-volatile scratch registers, R5..R12, to use.)

@0:     cmpwi   r5, 32
        ble+    @1

        ; OK...more than 32 bytes to move.  We'll move 28 bytes and then see if we can finish.
        ; (Why 28 bytes?  We're holding the length in R5, so we only have 7 scratch registers.)

        subi    r5, r5, 28

        lswi    r6, r4, 28
        addi    r4, r4, 28

        stswi   r6, r3, 28
        addi    r3, r3, 28

        b       @0

        ; We complete the move here, moving between 1 and 32 bytes.

@1:     mtxer   r5

        lswx    r5, r0, r4
        stswx   r5, r0, r3

        blr

;
; void pstrcatchr(unsigned char *dest, unsigned char src)
;
; Concatenate a single character onto a byte-counted string.
;

        export  pstrcatchr[DS]
        export  .pstrcatchr[PR]

        toc
            tc  pstrcatchr[TC], pstrcatchr[DS]

        csect   pstrcatchr[DS]
            dc.l    .pstrcatchr[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcatchr[PR]

        ; Get the byte count of the string; add one to it and store it back.

        lbz     r5, 0(r3)
        addi    r5, r5, 1
        stb     r5, 0(r3)

        ; Store the character we want to concatenate at the end of the string, and return.

        stbx    r4, r3, r5
        blr

;
; Boolean pstreq(unsigned char *s1, unsigned char *s2)
;
; Compare two byte-counted strings for equality; return true (1) if they're equal.
;

        export  pstreq[DS]
        export  .pstreq[PR]

        toc
            tc  pstreq[TC], pstreq[DS]

        csect   pstreq[DS]
            dc.l    .pstreq[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstreq[PR]

        ; First, get the byte count of both strings.

        lbz     r5, 0(r3)
        lbz     r6, 0(r4)

        ; If the byte counts aren't equal, fail immediately.

        cmpw    r5, r6
        bne     @fail

        ; OK, we have two strings of matching length.  Increment the addresses to point to
        ; the actual text of the strings.

        addi    r3, r3, 1
        addi    r4, r4, 1

        ; If the length is <= 16, we can complete the comparison in one pass.  We assume
        ; that this is the most common case, and hence set the branch-predict bit here.
        ; (Why 16 bytes?  We have 8 non-volatile scratch registers, R5..R12, to use.)

@0:     cmpwi   r5, 16
        ble+    @1

        ; OK...more than 16 bytes to compare.  We'll compare 12 bytes and then see if we can
        ; finish.  (Why 12 bytes?  The length is in R5, so we only have 7 scratch registers,
        ; and we can only use whole registers for the string-load instructions.)

        lswi    r6, r3, 12
        lswi    r9, r4, 12

        addi    r3, r3, 12
        addi    r4, r4, 12
        subi    r5, r5, 12

        ; Compare each of the register pairs R6/R9, R7/R10, R8/R11.  If any differs, exit.

        cmp     0, 0, r6, r9
        cmp     1, 0, r7, r10
        cmp     2, 0, r8, r11

        bne     0, @fail
        bne     1, @fail
        bne     2, @fail

        b       @0

        ; We complete the comparison here, comparing between 1 and 16 bytes.
        ; If R5 is zero, we succeed immediately.

@1:     cmpwi   r5, 0
        beq     @succ

        ; Load the strings into R5..R8 and R9..R12.  Save R5 first.

        mr      r0, r5
        mtxer   r5

        lswx    r5, r0, r3
        lswx    r9, r0, r4

        ; Compare R5 against R9; if they differ, fail.
        ; If they're the same, and R0 is <= 4, succeed.

        cmp     0, 0, r5, r9
        cmpi    1, 0, r0, 4

        bne     0, @fail
        ble     1, @succ

        ; Compare R6 against R10; fail if different.  Succeed if R0 <= 8.

        cmp     0, 0, r6, r10
        cmpi    1, 0, r0, 8

        bne     0, @fail
        ble     1, @succ

        ; Compare R7 against R11; fail if different.  Succeed if R0 <= 12.

        cmp     0, 0, r7, r11
        cmpi    1, 0, r0, 12

        bne     0, @fail
        ble     1, @succ

        ; compare R8 against R12; fail if different, succeed if same.

        cmpw    r7, r11
        bne     @fail

        ; Success!

@succ:  li      r3, 1
        blr

        ; Failure

@fail:  li      r3, 0
        blr

- ----- mylib.s.o.hqx

(This file must be converted with BinHex 4.0)
:#@ejE'PL,R-ZE`"B3dp'69"6)!#3"!CJ!*!%-AJ"h`!#UX9iiJ!!!`J!N!-T!*!
%,R4PH(3!N!d"N!!!N!0N!*!2)#jNBA4K!*!&!C!!!!!"N!!!N!0J!!!"p!!!!P3
!N!85!*!&3$LMrrmiK2rrM!3!!5`!N!1F"3!"3),rp%k!!##)T!!!1+8!!5`&!#"
!S3!F1+Arj(c%j+SiK!!FI-2PUMKM!"a,rrrNI+%$TRbJ*#TmS"dU6S!!)$LMrrm
iK2rrM!8!!5`!N!0!J[ri1+ArrS`%!!%X!*!$R!8!!8##rr41J!!JL--!!)LN!!"
mjLS8Q1-!!$KM!!%iK!!"I'-b&#`&!#"!S3!F1+Arj(c%j+SiK!!FI-2PUMKM!"a
,rrrNI+%$TRbJ*#TmS"dU6S!!))LM!!!iT3!"Q+-!!(b$+Dj1J!!JL+-!!)M%!!"
m"6!!3))!R$KM!!%iK!!",!8!%%#K!$4m`f5UI54NUMKM!!`iK!!-1+Arp(`'5!"
mKe!!I3KB!%##!'K!KJ"N3)S!B%[rrm`X"3!!3B)!6(bJ+hKmS31QI+!F+RdJ*#T
m"8J!,)!!"%##!$K!K3!XI!C3!#b!!!K!JJ!S3)8!((`(@!!XJ!!-3))!'%#&!!a
m"eJ!3))!$$KJ!!&1J!!J1'!!!%k!!#!!N!B"f!#3"a`!!!(B!*!(9!!!!GJ!N!H
!!!!"f!#3"m`!!!(B!*!(i!!!!GJ!N!B"N!!!!!'F!!!"U!!!!E3!!!(!!!!"c!!
!!C!!!*!$#4m!N!-"P!#3!`-I!*!$!C`!N!-2(`#3!`'J!*!$!am!N!-"U!#3!a8
I!*!$!D`!N!-$(`#3!`'d!*!$'am!N!-"Z!#3!`-I!*!$!F!!N!-K(`#3!`(%!*!
$!am!N!-"c!#3!bFI!*!$!G!!N!-$(`#3!`(B!*!$"am!N!-"h!#3!`dI!*!$!H!
!N!-6(`#3!`(N!*!$'4m!N!-"k!#3!amI!*!$!H`!N!-P(`"YH@aTBLjc!*!&rri
-!@F!N!i"!!"V!3#3#K%!N!G86d-!N!F"f!!#!!"V!3#3#K%2!*!0"!!!!GJ!!J!
!D`%!N!-%!*!'%3-!N!d1!!!"N!!!!J!!!J%!N!--!*!'%3S!N!dB!*!&!3!!!J%
!N!-F!*!'%3#3"h"cG(*MF(N!N!-"h!!#!!"V!3#3!`3!N!B4!`#3"R"cG(*MF(N
!N!-"R!!#!!!#!3#3!``!N!B4#J#3$5-!N!-F!!%!!!)"!*!$1!#3"K%!N!iX!!!
"i!!#!!"V!3#3!`3!N!B4!`#3$6B!!!'S!!)!!!)"!*!$$!#3"K%+!*!03!#3!e3
!!3!!!J%!N!-X!*!'%3#3"h"cG(*MBA3!N!-"j!!#!!"V!3#3!`3!N!B4!`#3"R"
cG(*MBA3!N!-"Y!!#!!!#!3#3!``!N!B4#J#3$8X!N!1!!!%!!!)"!*!$6!#3"K%
!N!j8!!!"k!!#!!"V!3#3!`3!N!B4!`#3$9m!!!(!!!)!!!)"!*!$$!#3"K%+!*!
0DJ#3!m`!!3!!!J%!N!-8!*!'%3#3"h"cG(*PF3#3"!(X!!)!!'X"!*!$"!#3"K%
$!*!'F(0dFQ9a!*!%!F`!!J!!!J%!N!--!*!'%3S!N!BZF(0dFQ9a!*!%i!!"!!!
#!3#3!l!!N!B4!*!+GQejAh0dFQ0`H3"YH9pcG(*MF(N!,QejAh0dFQ0`H3!ZF(0
dFQ0`H3"YH9pcG(*MBA3!EAPIFh4bBf&d!#jYH9pcG(*MBA3!,R"cG(*MBA3!F(0
dFQ0KG'0SFJ"`Fh4bBf&dBfKb!#j`Fh4bBf&dBfKb!1RK!!!:
--
Anton Rang ([e-mail])

---------------------------

>From [e-mail] (Brian Bechtel)
Subject: Tech Notes on the World Wide Web, and History Is Made
Date: 19 Oct 1994 16:49:23 -0700
Organization: Apple Computer, Inc., Cupertino, California

New excitement on the digital traffic jam.

Apple has now put all the tech notes (including the four new technotes
from the November developer CD which is _just_ going into the mail to
our developers right now as I type) on the Web.  Use Mosaic. Use MacWeb.
Use NetScape.  Explore.

 http://www.info.apple.com/dev/technotes/Main.html

The new tech notes include Jim Luther's "FL 37 Permission to do
What?!!?" (file permissions), Nitin Ganatra's "PS 02 Background-Only
Applications" (a revision of how to write faceless background
applications), Brian Bechtel's "OS 06 Control Strip Modules" (docs for
writing Control Strip modules, revised and corrected), and...

  Errata for Inside Macintosh:Networking

Yeah. That's right.  Rich Kubota and Scott Kuechle put together an
actual list of known errors in Inside Macintosh:Networking.  We have more
errata sheets under review, too.  When they get reviewed, we'll put them
up there as well.

For some help on getting started programming the Mac (and a desperate
plea for some feedback on said help), look at

 http://www.info.apple.com/dev/default.html

If you find this stuff useful, please let us know.  Thanks to Michelle
Wyner, ex-intern, and Mark Cookson for doing all the real work.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

If you don't know all these buzzwords, go read a different newsgroup
until you do.  Don't ask me; hell, I made up half of them myself.

---------------------------

End of C.S.M.P. Digest
**********************